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REMARKS 

Applicant has amended claims 1-3 and 5-6, cancelled 
claim 4 and added new claims 7-11. Accordingly, claims 1-3 and 
5-11 as presented are now pending in this application. A 
one-month extension petition is also transmitted herewith 
resetting the date for response to July 10, 2004. 

Because of the length of amendments made in the 
preliminary amendment filed by Applicant on December 8, 2000, 
the Examiner has required a substitute specification excluding 
the claims. Accordingly, Applicant submits herewith a 

substitute specification, including a marked-up and clean copy 
version in accordance with 37 C.F.R. § 1.125(b) and (c) , which 
contains subject matter from the original specification, the 
previously entered amendments under 37 C.F.R. § 1.121 and 
additional amendments to correct for further typographical 
errors uncovered by Applicant. The substitute specification 
includes no new matter. 

The Examiner has rejected claims 1-2 and 4-6 on 
various grounds under 35 U.S.C. § 112, second paragraph, 
including indef initeness and lack of antecedent basis. With the 
present amendment, Applicant has noted the phrases deemed 
problematic by the Examiner and has attempted to address any 
lack of antecedent basis or alleged indef initeness in the 
amended and newly presented claims. Accordingly, Applicant 
believes that the rejection of the claims under Section 112, 
second paragraph, should now be withdrawn. 

The Examiner has rejected claims 4-6 under 3 5 U.S.C. 
§ 101 alleging that claim 4 comprises a method that reads on a 
human user carrying out the invention mentally or mentally plus 
pencil and paper. Applicant disagrees with the basis of this 
rejection in view of the Federal Circuit's State Street Bank 
decision in 1998. In any event, as claim 4 has now been 
cancelled, Applicant believes that this rejection is now deemed 
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moot. Further, in newly presented method claims 9 and 10, 
Applicant has specified that the claimed methods are 
computer- implemented . 

Turning to the rejections based on prior art, the 
Examiner has rejected claims 1-6 under 35 U.S.C. § 103(a) as 
being unpatentable over Cook et al . , U.S. Patent No. 6,201,948 
("Cook") . Applicant respectfully traverses the rejection of the 
claims as obvious over CooJc as explained below. 

As a general matter, the Examiner states that content 
information, scenes, objects, shared scenes and shared objects 
are all disclosed in Cook. The Examiner also states that it 
would have been obvious to have included a "shared- scene setter" 
since Cook teaches the benefit of ultimately displaying content 
to a student. The Examiner further states that Cook teaches a 
"shared-object setter" and a "describer . " It is apparent, 
however, that Applicant's claimed use of its scenes and shared 
scenes are very different than any alleged "scene" or "shared 
scene" disclosed in Cook. 

By way of background, with Applicant's invention, 
content information is created and includes a number of scenes, 
each of which has at least one object. If the object is shared 
with at least two scenes, the object is a "shared object." A 
"shared scene" is a virtual scene that includes one or more 
objects and can be used alone or with other virtual scenes to 
form final scenes. 

Applicant's claimed invention uses shared scenes in a 
unique manner to create final scenes by converting virtual 
scenes, created by a user-friendly editing process that first 
specifies creating scenes using shared scenes (see Figure 18A) , 
into an output (shared object control information) that defines 
the scenes by shared objects, rather than by shared scenes. In 
other words, the control information, which is described based 
on specific shared scenes selected by the user, is converted 
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into shared object control information for forming scenes based 
on the shared objects in accordance with the predetermined 
specification (e.g., MHEG-IS) . 

Accordingly, it is clear that Cook does not disclose, 
teach or suggest the claimed invention, which allows a user to 
define scenes (such as MHEG scenes) using "shared scenes" 
without worrying about defining final scenes based on shared 
objects. This problem, described in the application, exists 
with current authoring tools, which only have a function to turn 
on or off a shared object simultaneously for all scenes, making 
it difficult for the author of a final scene to utilize a shared 
object effectively. By contrast, with the present invention, 
the user creates a shared scene using objects and then creates 
the desired resultant scene as a result of selecting shared 
scenes. This is shown, for example, in Figures 16C-16F where 
MHEG scene 1 is defined by shared scene 1 (shared scene 2 is 
"off") whereas MHEG scene 2 is defined by the combination of 
both shared scenes 1 and 2 (both are "on"). Shared scenes can 
be also superimposed to show and hide objects as shown for 
example in Figures 17A-17D. Cook lacks any disclosure, teaching 
or suggestion of the presently claimed invention and its novel 
use of shared scenes that converts scenes defined based on 
shared scenes to scenes defined based on objects in accordance 
with a predetermined specification, such as MHEG- 15 . 

Accordingly, it is respectfully submitted that the 
rejection of the claims based on Cook should be withdrawn. 

As it is believed that all of the rejections set forth 
in the Official Action have been fully met, favorable 
reconsideration and allowance are earnestly solicited. 

If, however, for any reason the Examiner does not 
believe that such action can be taken at this time, it is 
respectfully requested that he telephone Applicant's attorney at 
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(908) 654-5000 in order to overcome any additional objections 
which he might have. 

If there are any additional charges in connection with 
this requested amendment, the Examiner is authorized to charge 
Deposit Account No. 12-1095 therefor. 



Dated: July 6, 2004 




Jonathan A. David 
Registration No.: 36,494 
LERNER, DAVID, LITTENBERG, 
KRUMHOLZ St MENTLIK, LLP 
6 00 South Avenue West 
Westfield, New Jersey 07090 
(908) 654-5000 
Attorney for Applicant 
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(Marked-Up Copy) 
INFORMATION PROCESSING APPARATUS p^£Q£\\/ED 

JUL 1 3 2004 

background of the invention Technology Center 2100 

[0001] The present invention relates to an information 

processing apparatus used as the so-called authoring tool 
for creating broadcast contents such as MHEG (Multimedia 
Hypermedia Information Coding Expert Group) contents to be 
broadcasted along with video information. 

[0002] In recent years, fefee digital satellite 

broadcasting has been becominge popular. In comparison with 
the contemporary analog broadcasting, for example, fcke 
digital satellite broadcasting is well proof — againot better 
at preventing noise and fading, hence, bcing is capable of 
transmitting a signal with a high quality. In addition, the 
frequency utilization rate is improved and a multi-channel 
transmission can also be embraced. To put it concretely, in 
the case of the — digital satellite broadcasting, several 
hundreds of channels can be preserved by using one satellite. 
In such digital satellite broadcasting, it is possible to 
provide a number of special channels such as channels for 
sports, movies, music and news. Programs for special plans 
and contents of the channels are broadcasted through their 
respective channels . 

[0003] By utilizing such a digital broadcasting system, 

the user is capable of downloading musical data such as a 
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piece of music-^aaeL ^There also has been proposed a system^ 

called television shopping, that allows the user- £e*r 

example, to make a purchasing contract to buy some products 

while watching a broadcast screen ±a the oo called 

telcvioion ohopping . That is to say, the digital satellite 
broadcasting system broadcasts additional data services at 
the same time as an ordinary broadcast program. 
[0004] In the case of an operation to download musical 

data, for example, the broadcasting station broadcasts the 
musical data by multiplexing the data so as to synchronize 
the data with a broadcast program or video information. In 
addition, — if* — the — operation — fee — download — musical — data, the 
user is capable of carrying out downloading operations 
interactively while watching a displayed GUI (Graphical User 
Interface) screen which serves as a downloading operation 
screen. Data for displaying such a GUI screen is also 
broadcasted by multiplexing. 

[0005] Then, the user owning a reception apparatus 

selects a desired channel to display a GUI screen for 
downloading musical data by carrying out a predetermined 
operation on the reception apparatus. The user then carries 
out an operation #efon the GUI screen typically to supply 
the musical data to a digital audio apparatus connected to 
the reception apparatus. Typically, the musical data is 
recorded in the digital audio apparatus. 

[0006] Incidentally, with regard to a GUI screen for 



2 



downloading musical data described above, partial picture 
data and text data which are used as elements to form the 
GUI screen and unit data (or files) such as audio data to be 
output as a sound in accordance with a predetermined 
operation are each handled as an object. There — ha-s — been 
conceived — a — configuration — fee — implement — ncccooary — dioplay 
formats — aftd — output — format a — b€ — a — sound — a**d — the — like — by 
controlling an The output format of an object is controlled 
by a scenario description according to a predetermined 
system. That is to say, by broadcasting the so-called 
multimedia contents, a GUI screen described above is 
implemented . 

[0007] It should be noted that a GUI screen for 

implementing a function to achieve a certain objective by 
prescription of described information is referred to as a 
"scene". A scene also includes an output such as a sound. 
An "object" is defined as unit information such as a picture, 
a sound or a text with an output format thereof prescribed 
on the basis of described information. In addition, during 
transmission, a data file of described information itself is 
also handled as one of the objects. 

[0008] For example, as a system to prescribe a 

description of a content for broadcasting a GUI screen like 
the one described above, adoption of an MHEG (Multimedia 

Hypermedia Information Coding Experts Group) system is 

conceivable . 
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[0009] In an MHEG prescription, one MHEG content or one 

MHEG application file typically comprises one or more scenes. 
A script is described to prescribe transitions between 
scenes and outputs which are synchronized with typically 
broadcast pictures of the scenes. In addition, ia scene is 
controlled by a description of a script so that one or more 
objects of the scene are displayed in a predetermined 
display f ormat . 

[0010] In the broadcasting station, the MHEG content 

described above is created in accordance with broadcast 
contents by using typically a personal computer. On the 
personal computer, application software used as the £*o- 

callcd script creation tool or an authoring tool is 

activated. Such application software is referred to 

hereafter as an MHEG authoring tool, a generic name given to 
the software . 

[0011] Assume c Editing work is carried out in— typically 

in scene units by using the MHEG authoring tool described 
above. In general, objects to be displayed for a scene are 
selected- and the editor — then writes a description of a 
scenario so as to display the selected objects in desired 
display formats in the scene. As an alternative, a GUI 
screen is used as the authoring tool to create a scene — ie 
created by carrying out operations against , a GUI ocrccn used 
go gn authoring tool and, — finally, and editing results are 
described as a script. 
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[0012] Incidentally, a concept known as a shared object 

is prescribed in an MHEG application. 

[0013] A shared object is a file used as an object 

which is shared among scenes. 

[0014] With the contemporary MHEG authoring tool, 

however, there is provided only a function of merely 
selecting whether to use or diouoc of not use a shared object 
for an MHEG application unit. To put it in detail, it is 
possible only to select an option to display or not to 
display a shared object as an object common to all scenes 
compoo ing compr i s ing an MHEG application. 

[0015] Consider an attempt to effectively utilize a 

shared object. In this case, it is desirable to set any 
arbitrary shared object to be used or not to be used in each 
of scenes compoo ing compr i s ing an MHEG application. 
[0016] If any arbitrary shared object is to be assigned 

to a scene instead of being assigned to an MHEG application^ 
by uoing the contemporary MHEG authoring tool, — however, — the 
option of using or the option of not using a shared object 
in a scene must be set by using typically a description of 
an action to turn on or off individual objects created for 
the object. 

[0017] In order to set the option by using a 

description of such a script, it is necessary for the editor 
to sufficiently understand the description language. Thus, 
the setting the option weaek is a difficult job for the editor 
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In the end, it is quite within the bounds of possibility 
that the editor writes an incorrect description. For this 
reason, almost no editors use such a description to assign 
any arbitrary shared object to a scene in place of an MHEG 
application . 

[0018] In consequence, shared objects are not utilized 

effectively in the present state of the art. As a result, 
there are hindrances to diversification of display formats 
of MHEG contents. 
SUMMARY OF THE INVENTION 

[0019] It is therefore an object of the present 

invention to addressing the problems described above toby 
provide ing effective utilization of a shared object so as to 
allow the shared object to be handled with ease typically in 
creation of MHEG contents. 

[0020] In accordance with an aspect of the present 

invention, there is provided an information processing 
apparatus for creating content information according to a 
predetermined specification wherein the content information 
according to the predetermined specif ication io — created to 
includes a scene having created — fee — include — an object for 
creating the content information and — fee — include at least 
control information for controlling an output format of a 

scene or an object , fehe object. The content information 

according fee fehe predetermined specification — defines a 

shared object which can be used by being — shared among a 
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plurality of oocnco, — fc4* escenes . The information processing 
apparatus includiftges a shared- scene definition — mcano — #e*= 
definer operable to defin-3r**ge a shared scene as an editing 
material processible in the information processing apparatus 
where a shared scene is a virtual scene usable as a scene 
common to a plurality of scenes, a shared-scene creatieftor 
mcano — for creating operable to create the shared scene by 
using any arbitrary objects in accordance with a definition 
generated by the shared- scene definition — mcana def iner , a 
shared-scene setting — mcano — £e*= — setting — settor operable to 
set a specific shared scene to be used for each of the 
scenes forming the content information wherein the specific 
shared scene is selected among shared scenes created by the 
shared-scene creatieftor mcano , a shared-object getting mcano 
— octting — settor operable to set an object used in the 
specific shared scene as a shared object and a control- 
information dcocription mcano £e*? doocribing describer 

operable to describe control information for controlling a 
state of utilization of shared objects in each of the scenes 
in accordance with the predetermined specification and in 
dependence on a result of setting the specific shared scene 
carried out by the shared-scene setting means. 
[0021] According to the configuration described above, 

the information processing apparatus f unction-snags as an 
authoring tool for creating content information conforming 
to a predetermined specification and defines a shared scene 
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which is a virtual scene using a shared object usable as an 
object common to scenes. A& During scene editing, an edit 
operation to set a shared scene to be used for scenes is 
carried out to allow an object shared by a plurality of 
scenes to be handled. 

[0022] Then, after an object used in a shared scene has 

been set as a shared object, control information for 
controlling a utilization state of a shared object to be 
used for scenes in accordance with results of setting the 
shared scene for each scene is described in a format 
conforming to the predetermined specification described 
above . 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0023] Fig. 1 is a block diagram showing a typical 

configuration of a digital satellite broadcasting/reception 
system implemented by an embodiment of the present 
invention; 

[0024] Fig. 2 is a block diagram showing a typical 

configuration of a reception facility provided by the 
embodiment ,- 

[0025] Fig. 3 is a front -view diagram showing the 

external appearance of a remote controller for remotely 
operating an IRD; 

[0026] Figs. 4A and 4B are explanatory diagrams showing 

switching from a broadcast screen to a GUI screen and vice 
versa; 



8 



[0027] Fig. 5 is a block diagram showing a typical 

configuration of a ground station; 

[0028] Fig. 6 is a timing chart of data transmitted by 

the ground station; 

[0029] Figs. 7A to 7H are explanatory diagrams showing 

a time-division multiplexed structure of transmitted data; 
[0030] Figs. 8A to 8F are explanatory diagrams showing 

a DSM-CC transmission format; 

[0031] Fig. 9 is an explanatory diagram showing a 

typical directory structure of data services; 

[0032] Figs. 10A to IOC are diagrams showing the data 

structure of a transport stream; 

[0033] Figs. 11A to 11D are explanatory diagrams 

showing a table structure of a PSI; 

[0034] Fig. 12 is an explanatory diagram showing the 

configuration of the IRD; 

[0035] Fig. 13 is an explanatory diagram showing the 

structure of an MHEG content; 

[0036] Fig. 14 is an explanatory diagram showing the 

structure of an MHEG content; 

[0037] Fig. 15 is an explanatory diagram showing the 

concept of a shared object in an MHEG content; 

[0038] Figs. 16A to 16F are explanatory diagrams 

showing an example of scene editing using shared scenes; 
[0039] Figs. 17A to 17D are explanatory diagrams 

showing an example of scene editing using shared scenes; 
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[0040] Figs. 18A and 18B are explanatory diagrams 

showing the concept of processing embraced by an MHEG 
authoring tool provided by the embodiment; 

[0041] Fig. 19 is a block diagram showing functions of 

the MHEG authoring tool provided by the embodiment; 
[0042] Figs. 20A and 20B are explanatory diagrams 

showing a typical display format of an operation screen 
implemented by MHEG authoring software provided by the 
embodiment ; 

[0043] Fig. 21 is a flowchart representing processing 

operations carried out to create a shared scene; 
[0044] Fig. 22 is a flowchart representing processing 

operations carried out to set a shared scene for an MHEG 
scene; 

[0045] Fig. 23 is a flowchart representing processing 

operations carried out to output shared scene setting data 
as an MHEG script; and 

[0046] Fig. 24 is a flowchart representing processing 

operations carried out to output shared scene setting data 
as an MHEG script . 

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 
[0047] The present invention will become more apparent 

from a careful study of the following detailed description 
of a preferred embodiment with reference to accompanying 
diagrams . 

[0048] An information processing apparatus provided by 
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the present invention irs — baaed on — fefee — aaoumption — that — fetee 
apparatuo is used in a system which allows a program to be 
broadcasted by means of digital satellite broadcasting and 
information such as musical data or audio data related to 
the program to be downloaded on the receiver side. 
[0049] To be more specific, the information processing 

apparatus provided by the present invention is an authoring 
system for creating contents used by the broadcasting 
station as GUI data -ana — a — oyotcm — for broadcaoting — fc£te — 
data — for typically a downloading operation screen as data 
appended or synchronized to a program (or video information) 
using digital satellite broadcasting. 

[0050] In addition, an authoring system implemented by 

this embodiment is a system for creating MHEG contents. 

[0051] It should be noted that the description is given 

hereafter in the following order: 

1 Digital Satellite Broadcasting System 
1-1 Overall Configuration 

1-2 Operations for a GUI Screen 

1-3 Ground Station 

1-4 Transmission Format 

1- 5 IRD 

2 Authoring System 

2- 1 Structure of an MHEG Content 
2-2 Concept of a Shared Scene 

2-3 Configuration of the MHEG Authoring System 
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2-4 Typical GUI Screens Displayed as Part of MHEG Authoring 
Software 

2-5 Processing Operations 

1 Digital Satellite Broadcasting System 
1-1 Overall Configuration 

[0052] First of all, before explaining an MHEG 

authoring system implemented by this embodiment, a digital 
satellite broadcasting system using MHEG contents created by 
using this MHEG authoring system is explained. 

[0053] Fig. 1 is a block diagram showing the overall 

configuration of the digital satellite broadcasting system 
implemented by this embodiment. As shown in the figure, a 
ground station 1 in the digital satellite broadcasting 

system receives a material for television program 

broadcasting from a television program material server 6, a 
material of musical data from a musical data material server 
7, audio additional information from an audio additional 
information server 8 and GUI data from a GUI data server 9. 

[0054] The television program material server 6 is a 

server for providing a — material of an ordinary broadcast 
program. A material — e£ — a— musical broadcast transmitted by 
thiothe television program material server 6 includes moving 
pictures and sounds. In the case of a musical broadcasting 
program, for example, a material of moving pictures and 
sounds broadcasted by the television program material server 
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6 are used as moving pictures and sounds typically for 
promotion of new songs. 

[0055] The musical data material server 7 is a server 

for providing an audio program by using an audio channel. 
The material of an audio program is limited to sounds. The 
musical data material server 7 transmits materials of audio 
programs by way of a plurality of audio channels. 
[0056] In program broadcasting through audio channels, 

a particular piece of music is broadcasted repeatedly at 
unit time intervals. Audio channels are independent of each 
other. A variety of ways to use the audio channels a^eis 
conceivable. For example, an audio channel is used for 
broadcasting a number of most recent Japanese pope songs 
repeatedly at fixed intervals while another audio channel is 
used for broadcasting a number of most recent foreign pops 
songs repeatedly at fixed intervals. 

[0057] The audio additional information server 8 is a 

server for providing information on timee ing of music 
provided by the musical data material server 7. 

[0058] The GUI data server 9 provides GUI data (or data 

broadcasting contents - data ) uocd for forming a GUI screen 
used in conjunction with operations carried out by the user. 
In the case of formation of a GUI screen for downloading 
music as will be described later, for example, the GUI data 
server 9 provides, among other information, picture data and 
text data used for creating a list page and an information 
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page of pieces of music transmitted from the GUI data server 
9 and data for creating a still picture of an album jacket. 
In addition, the GUI data server 9 also provides EPG 
(Electrical Program Guide) data used for displaying a 

program known — as fcite oo called — BPG (Electrical Program 

Guide) — in a reception facility 3. 

[0059] It should be noted that GUI data conforms to 

typically the MHEG (Multimedia Hypermedia Information Coding 
Experts Group) system. The MHEG system is an international 
standard of scenario description for creation of a GUI 
screen. According to the MHEG system, multimedia information, 
procedures, operations and their combination are each taken 
as an object and, after each object has been coded, a title 

(such as a GUI screen) is created. In the case of this 
embodiment, the MHEG- 5 system is adopted. 

[0060] The ground station 1 transmits pieces of 

information received from the television program material 
server 6, the musical data material server 7, the audio 
additional information server 8 and the GUI data server 9 by 
multiplexing the pieces of information with each other. 

[0061] In this embodiment, video data and audio data 

received from the television program material server 6 have 
been subjected to an compression encoding process according 
to the MPEG2 (Moving Picture Experts Group 2) system and the 
MPEG2 audio system respectively. On the other hand, audio 
data received from the musical data material server 7 has 
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been subjected to a compression encoding process according 
to typically either the MPEG2 audio system or the ATRAC 
(Adoptive Transform Acoustic Coding) system depending on the 
audio channel . 

[0062] In the multiplexing process of the pieces of 

data in the ground station 1, the data is encrypted by using 
a key received from a key information server 10. 
[0063] It should be noted that a typical internal 

configuration of the ground station 1 will be described 
later . 

[0064] A signal transmitted by the ground station 1 by 

way of a satellite 2 is received by the reception facility 3 
of every home. The satellite 2 includes a plurality of 
transponders mounted thereon. A transponder has a typical 
transmission power of 30 Mbps. The reception facility 3 
installed in a home comprises a parabola antenna 11, an IRD 
(Integrated Receiver Decoder) 12, a storage device 13 and a 
monitor unit 14 . 

[0065] A remote controller 64 shown in the figure is 

used to remotely operate the IRD 12 . 

[0066] The parabola antenna 11 receives a signal 

transmitted by the ground station 1 by way of the satellite 
2. The received signal is converted into a signal having a 
predetermined frequency by an LNB (Low Noise Block Down 
Converter) 15 installed on the parabola antenna 11. The 
signal generated by the LNB 15 is supplied to the IRD 12. 
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[0067] General operations carried out by the IRD 12 

include selection of a signal transmitted as a predetermined 
audio signal among signals received by the parabola antenna 

11 and demodulation of the selected signal to extract video 
data and audio data as a program and output the video and 
audio data as video and audio signals respectively. The IRD 

12 also outputs a GUI screen based on GUI data received as 
multiplexed data in a program. The monitor unit 14 displays 
a picture of a program and outputs sounds of the program 
which haeve been selected by the IRD 12. In addition, the 
monitor unit 14 is also capable of displaying a GUI screen 
in accordance with an operation carried out by the user as 
will be described later. 

[0068] The storage device 13 is used for storing audio 

data (or musical data) downloaded by the IRD 12. Not 
specially limited to a particular storage type, the storage 
device 13 can be implemented by an MD (Mini Disc) 
recorder/player, a DAT recorder/player and a DVD 
recorder/player. In addition, the storage device 13 can also 
be implemented by a personal computer^ which is capable of 
storing audio data in recordable media such as the 
representative CD-R OM, besides a hard disc. 

[0069] Furthermore, the reception facility 3 provided 

by this embodiment may also employs- an MD recorder/player 
13A (Fig. 2) as the storage device 13 shown in Fig. 1. As 
shown in Fig. 2, the MD recorder/player 13A has a data 



16 



interface conforming to IEEE1394 data transmission 
specifications . 

[0070] The IEEE1394 MD recorder/player 13A shown in Fig. 

2 is connected to the IRD 12 by an IEEE1394 bus 16. Thus, 
audio data such as music received by the IRD 12 in this 
embodiment, that is, downloaded data, can be recorded 
directly with its compressed/encoded state of the ATRAC 
system sustained as it is. In addition, with the IEEE1394 MD 
recorder/player 13A connected to the IRD 12 by an IEEE13 94 
bus 16, it is also possible to record jacket data (or still- 
picture data) of the album and text data such as lyrics 
besides the audio data. 

[0071] The IRD 12 is capable of communicating with an 

accounting server 5 through typically a telephone line 4. An 
IC card for recording various kinds of information as will 
be described later is inserted into the IRD 12. When audio 
data of music is downloaded, for example, history 
information on the audio data is recorded onto the IC card. 
The history information recorded on the IC card is 
transmitted to the accounting server 5 at predetermined 
times and with predetermined timing by way of the telephone 
line 4. The accounting server 5 carries out charging by 
setting a transmission fee according to the history 
information received from the IRD 12. The transmission fee 
is then charged to the user. 

[0072] As — io obviouo from the dcocription given oo far, 
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4rn — fefee — oyotcm — fee — which — fetee — prooont — invention — i-s — applied, 
-fe-The ground station 1 transmits video and audio data used as 
a material of a musical program broadcast from the 
television program material server 6, audio data used as a 
material of the audio channel from the musical data material 
server 7, audio data from the audio additional information 
server 8 and GUI data from the GUI data server 9 by 
multiplexing the pieces of data with each other. 

[0073] Then, when this broadcast is received by the 

reception facility 3 of a home, a program of a selected 
channel can be watched typically on fefeea monitor unit 14. In 
addition, aa a GUI screen uaing GUI data received along with 
data of a program, — in the firot place, — an EPG (Electrical 
Program Guide) screen is displayed-; — allowing as a GUI Screen 
to allow the user to search the screen for a program. In the 
second place, by carrying out necessary operations for a— an 
EPG screen for a special service other than ordinary program 
broadcaoto, — for example, — in the caoc of thio embodiment, the 
user is capable of receiving a service other than ordinary 
programs presented by the broadcasting system to the user. 

[0074] By carrying out an operation for a displayed GUI 

screen for providing a service of downloading audio (or 
musical) data, for example, the user is capable of 
downloading the audio data of a desired piece of music and 
storing and keeping the data in the storage device 13. 

[0075] It should be noted that this embodiment exhibits 
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interact iveae&e ity in a data service broadcasting system for 
rendering special services other than the ordinary program 
broadcasts given in response to operations carried out for a 
GUI screen like the one described above. Such an interactive 
data service broadcasting system is called an interactive 
broadcasting system. 

1-2 Operations for a GUI Screen 

[0076] The following description briefly explains an 

example of the interactive broadcasting dcocribcd 
above , system and — fefeafe — ie-r typical operations to be carried 
out for a GUI screen, with reference to Figs. 3 and 4. In 
particular, downloading of musical data (or audio data) is 
explained . 

[0077] The description begins with an explanation of 

operation keys on fefeea remote controller 64 for use by the 
user to remotely carry out an operation on the IRD 12 with 
reference to Fig. 3. Cpccially Specif ically , main keys are 
explained . 

[0078] Fig. 3 is a diagram showing an operation panel 

surface of the remote controller 64. On the panel surface, a 
variety of switches are laid out. The keys include a power- 
supply key 101, numeric keys 102, a screen display switching 
key 103, an interactive switching key 104, an EPG key panel 
unit 105 and a channel key 106 to be explained as follows. 

[0079] The power-supply key 101 is operated to turn the 
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power supply of the IRD 12 on and off. A numeric key 102 is 
operated to specify a channel or enter a digit of a number 
to typically a GUI screen when a numeric input is required. 
[0080] The screen display switching key 103 is operated 

typically for switching the monitor display from an ordinary 
broadcast screen to an EPG screen and vice versa. Assume 
that an EPG screen is called by operating the screen display 
switching key 103. With the EPG screen displayed, a key 
provided on the EPG key panel unit 105 is operated to search 
the EPG screen for a program using a display screen of an 
electronic program guide. An arrow key 105a provided in the 
EPG key panel unit 105 can be operated also for moving a 
cursor on the GUI screen for rendering services to be 
described later. 

[0081] The interactive switching key 104 is operated 

for switching the monitor display from an ordinary broadcast 
screen to an GUI screen for rendering a service appended to 
a broadcast program and vice versa. 

[0082] The channel key 106 is operated to 

increment increase or dccrcmcnt decrease the number of a 
channel selected by the IRD 12 . 

[0083] It should be noted that the remote controller 64 

provided in this embodiment has a configuration that allows 
a variety of operations to be carried out against the 
monitor unit 14 and includes a variety of keys for the 
operations. However, description of the keys to be operated 
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for the monitor unit 14 is omitted. 

[0084] Next, an example of operations carried out for a 

GUI screen is explained by referring to Figs. 4A and 4B . 
[0085] When a broadcast is received by the reception 

facility 3 and a desired channel is selected, a display 
screen like one shown in Fig. 4A appears on the monitor unit 
14. As shown in the figure, the screen displays a moving 
picture based on a — program material received from the 
television program material server 6. That is to say, the 
contents of an ordinary program are displayed. In this 
example, a musical program is displayed. In addition, 
appended to this musical program is an interactive broadcast 
to render a service of downloading audio data of music. 
[0086] With the musical program displayed on the screen, 

assume for example that the user operates the interactive 
switching key 104 of the remote controller 64. In this case, 
the monitor display is switched to a GUI screen like one 
shown in Fig. 4B for downloading audio data. 

[0087] In the first place, in a television program 

display area 21A on the left top corner of this GUI screen, 
a reduced picture of video data of Fig. 4A received from the 
television program material server 6 is displayed. 

[0088] In addition, on the right top corner of the GUI 

screen, a list 21B of pieces of channel music broadcasted 
through audio channels is displayed. The left bottom corner 
of the GUI screen is allocated as a text display area 21C 
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and a jacket display area 2 ID. On the right side of the GUI 
screen, there — a*=e — dioplayod a lyrics display button 22, a 
profile display button 23, an information display button 24, 
a reservation-recording button 25, a completed- reservation- 
table display button 26, a recording-history-display button 
2 7 and a download button 2 8 are displayed . 

[0089] While looking at the names of the pieces of 

music on the list 21B, the user searches the list 21B for a 
piece of music which the user is interested in. If the user 
finds a piece of music of interest, the user opcratea the 
arrow key 105a of the EPC key panel unit 10D on the remote 

controller — 64 — and, after — moving moves the cursor to the 

display position of the piece of music of interest using the 
arrow key 105a and carries out- an enter operation ie 
carried out by typically by pressing the center position of 
the arrow key 105a. Such an operation, including moving the 
cursor to a displayed position and carrying out an enter 
operation, is hereafter referred to simply as an operation 
to press the button or pressing the button. 

[0090] By doing so, the user is capable of listening to 

the piece of music indicated by the cursor on a trial basis. 
Since the same music is broadcasted repeatedly during a 
predetermined unit period of time through any audio channel, 
it is possible to output the sound of the music of an audio 
channel selected by operating the IRD 12 and to listen to 
the selected music by switching the monitor display from an 
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original screen to the GUI screen with the original screen 
kept in the television program area 21A as it is. At that 
time, the still picture of the MCD jacket of the selected 
music is also displayed on the jacket display area 21D as 
well . 

[0091] In addition, if the user movco the curoor 

de presses the lyrics display button 22 and carrico out an 
enter operation in thia — atatc , the lyrics of the selected 
music 4rB — are displayed in the text display area 21C with 
timing synchronized to the audio data. An operation to move 
the cursor to the display position of a button and to carry 
out an enter operation io referred to hereafter oimply ao an 

operation — to prcoo — t^e — button. By the same token, if the 

profile display button 23 is pressed, the profile of an 
artist for the music is displayed in the text display area 
21C. Likewise, if the information display button 24 is 
pressed, information on the music such as a concert for the 
music is displayed on the text display area 21C. In this way, 
the user is capable of knowing what music is broadcasted at 
the present time and, furthermore, detailed information on 
each of the pieces of music. 

[0092] When the user wants to buy the piece of music of 

interest to the user, the user presses the download button 
28. As the download button 28 is pressed, the audio data of 
the selected music is downloaded and stored in the storage 
device 13. It is also possible to download other information 
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such as the lyrics, the profile of the artist and the still 
picture of the jacket along with the audio data of the music. 
[0093] Each time the audio data of music is downloaded 

in this way, its history information is stored in an IC card 
inserted into the IRD 12. Information stored in the IC card 
is transmitted to the accounting server 5 typically once a 
month to be used for computing a fee for data services 
rendered to the user. In this way, the copyright for the 
downloaded music can be protected. 

[0094] When the user wants to make an advance 

reservation for downloading, the user presses the 
reservation recording button 25. As the reservation 
recording button 25 is pressed, the monitor display is 
switched from the GUI screen to a screen fully used for 
displaying a list of all pieces of music which can be 
reserved. The list comprises pieces of music obtained as a 
result of a search operation carried out typically at hourly 
or weekly intervals and for each channel. The user then 
selects a piece of music to be subjected to reserved 
downloading from the list. Its related information is stored 
in the IRD 12. When the user wants to confirm a piece of 
music already subjected to reserved downloading, the user 
presses the completed-reservation- table display button 26 to 
use the entire screen for displaying a table of pieces of 
music already subjected to reserved downloading. A piece of 
music subjected to reserved downloading as described above 
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is downloaded to the IRD 12 and stored in the storage device 
13 at a reserved time. 

[0095] The user is also capable of confirming a piece 

of music already downloaded. In this case the user presses 
the recording history button 27 to use the entire screen for 
displaying a list of already downloaded pieces of music. 
[0096] As described above, in the reception facility 3 

of the system to which the present invention is applied, a 
list of pieces of music is displayed on the GUI screen of 
the monitor unit 14. Then, by selecting a piece of music 
from the list displayed on the GUI screen, the user is 
capable of listening to the selected music and viewing the 
lyrics and the profile of the artist of the music on a trial 
basis and knowing the lyrico and the profile of the artiat 
e£ — the — muoic . The user is also capable of displaying a 
history of reserv at ion ed downloading showing a list of 
pieces of music to be downloaded and a list of pieces of 
music already downloaded. 

[0097] As will be deacribed in detail later, fefee 

dioplay of — a — G^i — ocrccn — like — the — ene — ohown — in — Fig- — — a 
change A change may be made to the display on a GUI screen 
and a sound output may be programmed in response to an 
operation carried out by the user for the GUI screen can be ^ 
Such changes or modifications are implemented by 
prcocription — e# prescribing a relation among objects through 
dcocription of a scenario based on the MHEG system described 
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earlier. In this case, an object is picture data serving as 
parts corresponding to the buttons or material data 
displayed in the display areas displayed in Fig. 4B. 
[0098] In addition, in this specification, a scene is 

an environment in which a format to output information to 
achieve a certain purpose such as the display of a picture 
or an operation to output a sound is implemented by 
prescription of a relation among objects through description 
of a scenario. A file containing the description of a 
scenario itself is also handled as one of the objects 
forming a scene. 

[0099] As described above, in a digital satellite 

broadcasting system to which the present invention is 
applied, a broadcast program is distributed by communication 
In addition, audio data of music is also broadcasted through 
a plurality of audio channels. The user is allowed to search 
a list of distributed pieces of music for a desired one and 
to store the audio data of the desired music in the storage 
device 13 with ease. 

[0100] It should be noted that a variety of conceivable 

implementations of services other than the service of 
providing programs in the digital satellite broadcasting 
system are not limited to the service of downloading of 
musical data described above. As a conceivable example of 
such implementation, there is provided the so-called 
television shopping whereby a products- introducing program 
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is broadcasted and a GUI screen is used to make a purchasing 
contract . 

1-3 Ground Station 

[0101] An overview of the digital satellite 

broadcasting system implemented by an embodiment of the 
present invention has been described so far. The following 
description explains the system in more detail. The 
description begins with an explanation of the configuration 
of the ground station 1 with reference to Fig. 5. 

[0102] The explanation given thereafter is based on the 

following assumption. 

[0103] In the transmission of data from the ground 

station 1 to the reception facility 3 by way of the 
satellite 2 in this embodiment, a DSM-CC (Digital Storage 
Media-Command and Control) protocol is adopted. 

[0104] As is already known, the DSM-CC (MPEG-part 6) 

system prescribes commands or a control system for 
retrieving an MPEG-encoded bit stream stored in DSM (Digital 
Storage Media) or storing such a stream in the DSM typically 
by way of some networks. In this embodiment, the DSM-CC 
system is adopted as a transmission standard in the digital 
satellite broadcasting system. 

[0105] In order to transmit a content (that is, a set 

of objects) of a data broadcasting service such as a GUI 
screen in accordance with the DSM-CC system, it is necessary 
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to define the description format of the content. In this 
embodiment, for definition of this description format, the 
MHEG system explained earlier is embraced. 

[0106] In the configuration of the ground station 1 

shown in Fig. 5, a television program material cataloging 
system 31 catalogs material data obtained from the 
television program material server 6 in an AV server 35. The 
material data is supplied to a television program output 
system 3 9 in which video data is compressed in accordance 
with typically the MPEG2 system while audio data is 
converted into packets conforming to typically the MPEG2 
audio system. Data output by the television program output 
system 39 is supplied to a multiplexer 45. 

[0107] A musical data material cataloging system 32 

receives material data , or audio data, from the musical data 
material server 7- — □ upp 1 y i ng and s upp lies the material data, 
that — ie-j — audio — data, — to an MPEG2 audio encoder 3 6A and an 
ATRAC audio encoder 36B. In the MPEG audio encoder 36A, the 
audio data is subjected to an encoding process or, to be 
more specific, a compression-encoding process, before being 
cataloged in an MPEG audio server 4 OA. By the same token, in 
the ATRAC audio encoder 3 6B, the audio data is subjected to 
an encoding process or, to be more specific, a compression- 
encoding process, before being cataloged in an ATRAC audio 
server 40B. 

[0108] The MPEG audio data cataloged in the MPEG audio 
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server 4 OA is then supplied to an MPEG audio output system 
43A to be converted into packets before being supplied to 
the multiplexer 45. Likewise, the ATRAC audio data cataloged 
in the ATRAC audio server 40B is then supplied to an ATRAC 
audio output system 43B as quadruple -speed ATRAC data to be 
converted into packets before being supplied to the 
multiplexer 45. 

[0109] An audio additional information cataloging 

system 33 catalogs material data, that is, audio additional 
information, received from the audio additional information 
server 8 into an audio additional information data base 37. 
The audio additional information cataloged in the audio 
additional information data base 37 is then supplied to an 
audio additional information output system 41 to be 
converted into packets before being supplied to the 
multiplexer 45. 

[0110] A GUI material cataloging system 34 catalogs 

material data, that is, GUI data, received from the GUI data 
server 9 into a GUI material data base 38. 

[0111] The GUI material data cataloged in the GUI 

material data base 3 8 is then supplied to a GUI authoring 
system 42 for carrying out processing to convert the GUI 
material data into data of a format that can be output as a 
GUI screen, that io, — a such as the scene described earlier 
by referring to in Figs . 4A and 4B . 

[0112] That is to say, if the scene is a GUI screen for 
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downloading music, for example, data supplied to the GUI 
authoring system 42 is still picture data of an album jacket, 
text data of lyrics or the like or sound data to be output 
in accordance with an operation. 

[0113] The pieces of data cited above are called 

monomedia data. In the GUI authoring system 42, an MHEG 
authoring tool is used to encode the pieces of monomedia 
data so as to allow them to be handled as objects. 

[0114] Then, an MHEG- 5 content is created along with a 

scenario description file (referred to as a script) 
prescribing a relation among objects so as to obtain a 
display format of a scene (that is, a GUI screen) like the 
one explained earlier by referring to Fig. 4B and a format 
of picture sounds output in response to an operation. 

[0115] As shown in Fig. 4B, the GUI screen also 

displays picture/sound data -(-comprising MPEG video data a*td 
MPEG — audio data) — based on material data received from the 
television program material server 6 and MPEG audio data 
based on musical material data received from the musical 
data material server 7 in an output format according to an 
operation . 

[0116] Thus, as the aforementioned scenario description 

files, the GUI authoring system 42 handles picture/sound 
data based on material data received from the television 
program material server 6, MPEG audio data based on musical 
material data received from the musical data material server 
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7 and audio additional information received from the audio 
additional information server 8 as objects when necessary 
and creates an MHEG script for prescribing the relation 
among the objects. 

[0117] It should be noted that data of an MHEG content 

transmitted by the GUI authoring system 42 includes script 
files, a variety of still -picture data files each handled as 
a**— object and text files (and audio data files) . The still 
picture data is data of 720 pixels X 480 pixels compressed in 
accordance with typically the JPEG (Joint Photograph Experts 
Group) system whereas the text data is a file with a size 
not exceeding typically 800 characters. 

[0118] Data e£ — a acontaining MHEG content obtained in 

the GUI authoring system 42 is supplied to the DSM-CC 
encoder 44 . 

[0119] The DSM-CC encoder 44 converts the data received 

from the GUI authoring system 42 into a transport stream 
with a format that can be multiplexed into a data stream of 
video and audio data conforming to an in MPEG2 format . and 
packctiEco tThe transport stream before oupplying it (TS) is 
made into a packet and supplied to the multiplexer 45. ife 
ohould bo noted that the tranoport otrcam io aloo hereafter 
abbreviated to a TS . 

[0120] The multiplexer 45 multiplexes video and audio 

packets received from the television program output system 
39, audio packets received from the MPEG audio output system 
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43A, quadruple -speed audio packets received from the ATRAC 
audio output system 43B, audio additional information 
packets received from the audio additional information 
output system 41 and GUI data packets received from the GUI 
authoring system 42 along the time axis and encrypts them in 
accordance with key information output by the key 
information server 10 shown in Fig. 1. 

[0121] The multiplexed data output by the multiplexer 

45 is supplied to a wave output system 46 which typically 
carries out processing such as addition of error correction 
codes, and modulation and frequency transformation before 
supplying the multiplexed data to the satellite 2 by way of 
an antenna. 

1-4 Transmission Format 

[0122] The following description explains a 

transmission format which is adopted by this embodiment and 
prescribed on the basis of the DSM-CC system. 

[0123] Fig. 6 is a diagram showing an example of data 

transmitted by the ground station 1 to the satellite 2. It 
should be noted that, as described before, pieces of data 
shown in the figure are actually multiplexed along the time 
axis. In Fig. 6, a period between points of time tl and t2 
shown in the figure is defined as an event. In the case of a 
musical -program channel, for example, an event is a unit for 
changing a line-up of a plurality of pieces of music. In 
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this case, the event has a length of approximately 3 0 
minutes to 1 hour. 

[0124] As shown in Fig. 6, in the event between the 

points of time tl and t2, a program having predetermined 
contents Al is broadcasted as a broadcast of an ordinary 
moving-picture program. In an event starting at the point of 
time t2, contents A2 are broadcasted. In this ordinary 
program, a moving picture and sounds are broadcasted. 

[0125] In this example, 10 channels, namely, CHI to 

CH10, are provided to serve as MPEG audio channels (1) to 

(10). Through each of the audio channels CHI, CH2, CH3 , , 

CH10, the same music is transmitted repeatedly during the 
broadcasting time of an event. To be more specific, during 
the period of the event between the points of time tl to t2, 
music Bl, music CI and so on are transmitted repeatedly 
through audio channels CHI, CH2 and so on respectively. 
Through the last audio channel CH10, music Kl is transmitted 
repeatedly. The repeated transmission described is also 
carried out through each of quadruple -speed ATRAC audio 
channels (1) to (10) . 

[0126] That is to say, an MPEG audio channel indicated 

by a number enclosed in parentheses ( ) as shown in the 
timing diagram of Fig. 6 is used for transmitting the same 
music as a quadruple -speed ATRAC audio channel indicated by 
the same number enclosed in parentheses ( ) . In addition, 
audio additional information indicated by a channel number 
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enclosed in parentheses ( ) is added to audio data 
transmitted through an audio channel indicated by the same 
number enclosed in parentheses ( ) . Furthermore, still- 
picture data and text data transmitted as GUI data are also 
formed for each audio channel. As shown in Figs. 7A to 7D, 
pieces of still-picture data and text data are multiplexed 
in transmitted MPEG2 transport packets on a time-division 
basis. As shown in Figs. 7E to 7H, the packets are 
demultiplexed in the IRD 12 to reconstruct the original GUI 
data based on header information of each of the packets. 
[0127] There is at least GUI data among pieces of 

transmitted data shown in Figs. 6 and 7A to 7H. ThioA s 
previously discussed, this GUI data is used in data services, 
that io, such as broadcasting or interactive broadcasting of 
MHEG contents synchronized with TV broadcasting or audio 
broadcasting. This GUI data is logically formed in 
accordance with the DSM-CC system as follows. The formation 
of the GUI data is exemplified only by data of a transport 
stream output by the DSM-CC encoder 44. 

[0128] As shown in Fig. 8A, files to be transmitted in 

a data broadcasting service in this embodiment in accordance 
with the DSM-CC system are all included in a root directory 
named Service Gateway. Types of objects contained in the 
Service Gateway include directories, files, streams and 
stream events. 

[0129] Files are individual data files for storing, 
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among other information, a still picture, a sound, a text 
and a script described in conformity with the MHEG system. 
[0130] A stream typically includes information linked 

to another data service and an AV stream such as MPEG video 
data used as a TV program material, audio data, MPEG audio 
data used as a musical material and ATRAC audio data. 
[0131] A stream event includes links and time 

information. 

[0132] A directory is a folder which is a collection of 

pieces of data related to each other. 

[0133] As shown in Fig. 8B, in the DSM-CC system, these 

pieces of unit information and the Service Gateway itself 
are each handled as a unit known as an object which is 
converted into a format referred to as a BIOP message. 
[0134] It should be noted that, in the explanation of 

the present invention, the classification of objects into 
files, streams and stream events is not essential. Thus, in 
the following description, the file is used as a 
representative obj ect . 

[0135] In addition, in the DSM-CC system, a data unit 

known as a module shown in Fig. 8C is generated. The module 
comprises one or more objects which are each converted into 
a BIOP message as shown in Fig. 8B . The module is a 
variable-length data unit including an additional BIOP 
header. This data unit is a buffering unit of data received 
on the reception side to be described later. 
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[0136] The DSM-CC system does not specially prescribe 

nor limit a relation among objects in the case of a module 
formed from a plurality of objects. In other words, opoaking 
about in an extreme case, a module can be formed from 2 or 
more objects in scenes not related to each other at all 
without violating a prescription based on the DSM-CC system 
whatoocvor . 

[0137] In order to transmit data in the form of 

sections prescribed by an MPEG2 format, the module is split 
into data units each basically having a fixed length as 
shown in Fig. 8D . This data unit is referred to as a 
mechanical block. It should be noted, however, that the last 
block in the module is not necessarily required to have a 
fixed length. The reason why the module is split into blocks 
in this way is that, in the MPEG2 format, there is a 
prescription stating that 1 section shall not exceed 4 KB. 

[0138] In this case, what is meant by a section is a 

data unit defined as a block as described above. 

[0139] As shown in Fig. 8E, a block obtained as a 

result of division of a module described above is converted 
into a message known as a DDB (Download Data Block) to which 
a header is added. 

[0140] Concurrently with the conversion of a block into 

a DDB described above, control messages called a DSI 
(Download Server Initiate) and a DII (Download Indication 
Information) are generated. 
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[0141] The DSI and the DII are information required 

4rRto acquiriftge a module from data received by the IRD 12 on 
the reception side. The DSI includes mainly an identifier of 

a carouocl (module) data transmission system known as a 

carousel (Fig. 8F) or module and information on the carousel 

as a wholes , including the The information on a carouocl - 

includco a time the carousel takes to make 1 rotation and a 
time-out value of the carousel rotation. The information may 
also include data uocd for knowing where on the location of 
the root directory (Service Gateway) of the data services 
cxioto in the case of an object carousel system. 

[0142] The DII is information corresponding to each 

module included in a carousel. To be more specific, the DII 
is information such as the size and the version of each 
module and the time-out value of the module. 

[0143] Then, as shown in Fig. 8F, the 3 types of 

messages, namely, the DDB, the DSI and the DII, are output 
periodically and repeatedly by associating the messages with 
data units. In this way, the receiver is capable of 
receiving a module including an object required to obtain 
typically the desired GUI screen (or scene) at any time. 
[0144] In this specification, the transmission system 

is called a carousel system if we compare the system with a 
merry-go-round. The data transmission technique 

representifi§ed by a model shown in Fig. 8F is known as a 
carousel . 
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[0145] carousel may include a plurality of modules. 

For example, a plurality of modules required in a data 
service can be transmitted by using a carousel. 
[0146] In addition, the carousel system is divided into 

2 levels, namely, a data carousel system and an object 

carousel system. Particularly, i« — feThe object carousel 

system is a oyotcm capable of handling a directory structure 
wherein an object having an attribute of a file, a directory, 
a stream, a service gateway or the like is transmitted as 

data by — using a carousel-? making a bi^ a significant 

difference from the data carousel system. In the system 
implemented by this embodiment, the object carousel system 
is embraced. 

[0147] Fig. 9 is a diagram showing a typical directory 

structure of files (strictly speaking, MHEG application 
files) as a data service according to the MHEG system. As 
described above, the object carousel system is characterized 
in that the system is capable of handling a directory 
structure . 

[0148] Normally, an MHEG application file serving as an 

entrance to a service domain is always a file called 
appO/startup placed right below the Service Gateway. 

[0149] Basically, beneath the service domain (Service 

Gateway), application directories appO, appl, , appN 

exist. Beneath each of the application directories, an 
application file called startup and directories of scenes 
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composing the application exist. The directories of scenes 
are sceneO, scenel and so on. Beneath each of the scene 
directories, an MHEG scene file and content files composing 
the scene exist . 

[0150] In addition, broadcast data including GUI data 

transmitted by using a carousel as described above, that is, 
data produced by the multiplexer 45 shown in Fig. 5, is 
output in the form of a transport stream which has a typical 
structure like one shown in Figs. 10A to IOC. 

[0151] Fig. 10A is a diagram showing a transport stream 

This transport stream is a bit stream defined by the MPEG 
system. As shown in the figure, the transport stream is a 
concatenation of packets (strictly speaking, transport 
packets) each having a fixed length of 188 bytes. 
[0152] Each of the transport packets is shown in Fig. 

10B. As shown in the figure, a transport packet comprises a 
header, an adaptation field for including additional 
information in this particular individual packet and a 
payload (or a data area) representing contents of the packet 
including video and audio data. 

[0153] In actuality, the header is typically 4 bytes in 

length. As shown in Fig. 10C, the header always includes a 
synchronization byte at the beginning. At predetermined 
positions behind the synchronization byte, there are stored 
a PID (Packet_ID) serving as identification information of 
the packet, scramble control information indicating 
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absence/presence of a scramble and adaptation field control 
information indicating, among others, absence/presence of 
the subsequent adaptation field and the payload. 

[0154] The reception apparatus carries out a 

descrambling process based on these pieces of control 
information in packet units. Then, a demultiplexer can be 
used for separating and extracting needed packets such as 
video and audio data. In addition, it is also possible to 
reproduce time information used as a reference of a 
synchronous playback operation of video and audio data. 

[0155] As is obvious from the description given so far, 

a transport stream comprises multiplexed packets of audio 
and video data pertaining to a plurality of channels. In 
addition, aloo multiplexed at the oamc time in the tranoport 

atrcam a^e a signal called PSI (Program Specific 

Information) for implementing selection of a station, 
information (EMM/ECM) required for limited reception and SI 

(Service Information) for implementing services such as an 
EPG are also multiplexed at the same time in the transport 
stream . The limited reception is a reception function for 
determining whether or not it is possible to receive data 
through a fee -charging channel in dependence on the 
condition of a contract made with an individual. 

[0156] The PSI which comprises 4 tables is explained by 

referring to Figs. 11A to 11D. Each of the tables is 
expressed in a format conforming to an MPEG system known as 
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a section format. 

[0157] Fig. 11A is a diagram showing an NIT (Network 

Information Table) and a CAT (Conditional Access Table) . 
[0158] The same contents of the NIT are multiplexed for 

the entire carrier. The NIT includes transmission parameters 
such as a plane of polarization, a carrier frequency and a 
convolution rate as well as a list of channels superposed 
thereon. The PID of the NIT is set at 0x0010. 

[0159] The same contents of the CAT are also 

multiplexed for the entire carrier. The CAT includes the PID 
of an EMM (Entitlement Management Message) packet which is 
individual data such as contract information and an 
identification of the limited-reception system. The PID of 
the CAT is set at 0x0001. 

[0160] Fig. 11B is a diagram showing PATs which are 

each provided for a carrier. A PAT is information having 
contents peculiar to the carrier for which the PAT is 
provided. A PAT includes channel information in the 
associated carrier and the PID of a PMT representing 
contents of channels. Its PID is set at 0x0000. 

[0161] Fig. 11C is a diagram showing PMTs (Program Map 

Table) which are each provided for a channel. A PMT is 
information for a channel in the carrier. 

[0162] PMTs with contents varying from channel to 

channel are multiplexed. For example, the PID of a PMT shown 
in Fig. 11D is specified by a PAT . As shown in the figure, 
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the PMT includes components (such as video and audio data) 
composing the channel and the PID of an ECM (Encryption 
Control Message) packet required for descrambling . 

[0163] Shown — in — none — &€ — the — f igurca, ferThe SI (not 

shown) is a table with a section format like the PSI. The 
table includes information on an EPG. On the IRD side, 
necessary information is extracted from the table and 
displayed on a screen. 

[0164] Representative tables of the PSI are an SDT 

(Service Description Table) and an EIT (Event Information 
Table) . 

[0165] The SDT represents information on a channel 

including the number, the name and contents of the channel. 
Its PID is set at 0x0011. 

[0166] On the other hand, the EIT represents 

information on a program including the name, the start time, 
the outline of the program and a genre. Its PID is set at 
0x0012 . 

1-5 IRD 

[0167] Next, a typical configuration of the IRD 12 

provided in the reception facility 3 is explained by 
referring to Fig. 12. 

[0168] In the IRD 12 shown in the figure, a signal is 

received by an input terminal Tl, being supplied to a 
tuner/front-end unit 51. The signal has been subjected to a 
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predetermined frequency- transformation process in the LNB 15 
of the parabola antenna 11. 

[0169] The tuner/ front -end unit 51 also receives a 

setting signal including transmission parameters from the 
CPU (Central Processing Unit) 80. The setting signal is used 
to determine the frequency of a carrier to be received. The 
tuner/ front -end unit 51 then carries out processing such as 
bitabi demodulation and error correction to obtain a 
transport stream. 

[0170] The transport stream obtained by the 

tuner/ front -end unit 51 is supplied to a descrambler 52. In 
addition, the tuner/ front -end unit 51 also acquires a PSI 
packet from the transport stream to update its information 
on selection of a station. The tuner/front-end unit 51 
supplies the component PID of each channel obtained from the 
transport stream to typically the CPU 80 which uses the PID 
for processing the received signal. 

[0171] The descrambler 52 receives descrambler-key data 

stored in an IC card 65 by way of the CPU 80. A PID is set 
by the CPU 80. Then, the descrambler 52 carries out 
descramble processing based on this descramble key data and 
the PID, supplying a result of the descramble processing to 
a transport unit 53 . 

[0172] The transport unit 53 comprises a demultiplexer 

70 and a queue 71 which is typically implemented by a DRAM 
or the like. The queue 71 is an array of a plurality of 
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memory areas each corresponding to a module unit. In the 
case of this embodiment, for example, the array comprises 32 
memory areas. Thus, information of up to 32 modules can be 
stored in the queue 71. 

[0173] The operation of the demultiplexer 70 is 

explained briefly as follows. In accordance with a filter 
condition set by a DeMUX driver 82 employed in the CPU 80, a 
necessary transport packet is extracted from the transport 
stream received from the descrambler 52 and, if necessary, 
the queue 71 is used as a work area to obtain pieces of data 
with formats like the ones shown in Figs. 7E to 7H. The 
pieces of data are then supplied to their respective 
functional circuits requiring them. 

[0174] The MPEG video data and the MPEG audio data are 

separated by the demultiplexer 70 a^eand supplied to an 
MPEG2 video decoder 5 5 and tfeean MPEG audio decoder 54 
respectively. Individual packets of the separated video and 
audio data are supplied to their respective decoders in a 
format known as a PES (Packet Elementary Stream) . 

[0175] As for data of MHEG contents in the transport 

stream, the demultiplexer 70 separates and extracts the data 
from the transport stream in transport -packet units and 
stores them in appropriate memory areas in the queue 71 so 
as to collect the data for each module. The data of MHEG 
contents collected for each module is then written into a 
DSM-CC buffer 91 of a main memory 90 to be stored there by 
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way of a data bus under control executed by the CPU 80 . 
[0176] In addition, also in the case of the quadruple- 

speed ATRAC data (that is, compressed audio data) in a 
transport stream, necessary data is separated and extracted 
by the demultiplexer 70 typically in transport-packet units 
which are then output to an IEEE1394 interface 60. In 
addition to audio data, video data and a variety of command 
signals or the like can also be output by way of the 
IEEE1394 interface 60. 

[0177] The MPEG video data having a PES format supplied 

to the MPEG2 video decoder 55 is subjected to a decoding 
process according to the MPEG2 format with a memory 55A used 
as ar the work area. The decoded video data is then supplied 
to a display processing unit 58. 

[0178] In addition to the decoded video data received 

from the MPEG2 video decoder 55, the display processing unit 
58 also receives video data such as a GUI screen for data 
services obtained from an MHEG buffer 92 of the main memory 
90 as will be described later. In the display processing 
unit 58, the video data received thereby is subjected to 
necessary signal processing for converting the data into an 
analog audio signal conforming to a predetermined television 
system. The analog audio signal is then output to an analog 
video output terminal T2 . 

[0179] By connecting the analog video output terminal 

T2 to a video input terminal of the monitor unit 14, a 
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screen like the one shown in Figs. 4A and 4B can be 
displayed on the monitor unit 14. 

[0180] The PES MPEG audio data supplied to the MPEG2 

audio decoder 54 is subjected to a decoding process 
according to the MPEG2 format with the memory 54A used as a 
work area. The decoded video data is supplied to a D/A 
converter 56 and an optical digital output interface 59. 
[0181] In the D/A converter 56, the decoded video data 

received thereby is converted into an analog audio signal 
which is then supplied to a switch circuit 57. The switch 
circuit 57 switches the signal path so as to supply the 
analog audio signal to either an analog audio output 
terminal T3 or an analog audio output terminal T4 . 
[0182] The analog audio output terminal T3 is a 

terminal — to be connected to an audio input terminal of the 
monitor unit 14. On the other hand, the analog audio output 
terminal T4 is a terminal for outputting downloaded music as 
an analog signal. 

[0183] In addition, the optical digital output 

interface 59 converts digital audio data received thereby 
into an output optical digital signal. In this case, the 
optical digital output interface 59 conforms typically to 
the IEC 958. 

[0184] The main memory 90 is used as a work area in 

various kinds of control processing carried out by the CPU 
80. In this embodiment, the main memory 90 includes areas 
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used as the DSM-CC buffer 91 and the MHEG buffer 92 
described earlier. 

[0185] The MHEG buffer 92 is a work area used for 

creating picture data (such as picture data of a GUI screen) 
generated in accordance with a script conforming to the MHEG 
system. The picture data generated by using the MHEG buffer 
92 is supplied to the display processing unit 58 by way of a 
bus line. 

[0186] The CPU 80 executes overall control in the IRD 

12. Thus, the CPU 80 also controls the separation and the 
extraction of data in the demultiplexer 70. 

[0187] The CPU 80 also decodes data of MHEG contents 

acquired thereby in order to form a GUI screen (or a scene) 
in accordance with described contents of a script and output 
the screen. 

[0188] In order to accomplish the functions described 

above, the CPU 80 employed in this embodiment is typically 
provided with at least the DeMUX driver 82, a DSM-CC decoder 
block 83 and an MHEG decoder block 84 in addition to a 
control processing unit 81. In this embodiment, among 
components of the CPU 80, at least the DSM-CC decoder block 
83 and the MHEG decoder block 84 are implemented by software. 
[0189] The DeMUX driver 82 sets a filter condition in 

the demultiplexer 70 on the basis of the PID of an input 
transport stream. 

[0190] The DSM-CC decoder block 83 functions as a DSM 
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manager, reconstructing data of MHEG contents for — a# a 
module unit stored in the DSM-CC buffer 91. In addition, the 
DSM-CC decoder block 83 also carries out processing related 
to a necessary DSM-CC decoding process in accordance with 
accesses from the MHEG decoder block 84. 

[0191] The MHEG decoder block 84 carries out decode 

processing for outputting a scene by making — a** — acccoo — fee 
accessing data of MHEG contents in the DSM-CC buffer 91 
obtained by the DSM-CC decoder block 83, that is, data of an 
MHEG content obtained in the DSM-CC buffer 91. That is to 
say, the MHEG decoder block 84 creates a scene by 
implementing a relation among objects prescribed by a script 
file of the MHEG content. In the creation of a GUI screen 
used as the scene, the MHEG buffer 92 is used to generate 
data of a rthe GUI screen in accordance with the contents of 
the script file. 

[0192] As an interface between the DSM-CC decoder block 

83 and the MHEG decoder block 84, a U-U API (DSM-CC U-U API 
(Application Portability Interface)) is adopted. 
[0193] The U-U API is an interface used by a client 

(the MHEG decoder block 84) for malting an al lowing access to 
a DSM Manager object which is an object for implementing a 
DSM function (the DSM-CC decoder block 83) . To be more 
specific, the U-U API is an API for allowing as structural 
access be — made — otructurally — se — as — to treat objects each 
having an attribute like a file system. Examples of such 
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objects are the Service Gateway, directories, files, streams 
and stream events which are included in the carousel. 
[0194] Thus, an — access to an object included in the 

carousel can be made through the API by merely specifying a 
bus name without the necessity for a program (or a client) 
using the carousel to be concerned with a carousel reception 
operation. 

[0195] In addition, the U-U API is a set of interfaces 

prescribed to be usable without regard to a data transfer 
system at a low layer. Thus, a program utilizing this API 
has a merit of an ability to use this API in any data 
transfer system providing the U-U API . 

[0196] The following description explains a typical 

operation to extract a desired object required for creation 
of ia scene from a transport stream in accordance with 
control executed by the CPU 80. 

[0197] In the DSM-CC protocol, an IOR (Interoperable 

Object Reference) is used for indicating the location of an 
object in a transport stream. An IOR includes an identifier 
corresponding to a carousel for finding the object, an 
identifier of a module including the obi ect (hereinafter 
"module id" ) , an identifier for identifying the object in 
the module (hereinafter "object key") and a tag for 
identifying a DII having information on the module including 
the object (hereinafter "association tag") . *Fhe — identifier 
of the module, — the identifier of the object and the tag arc 
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referred to hereafter ao a modulc_id, — an objcct_kcy and an 
aooociation_tag roopect ivoly . 

[0198] The DII having information on the module 

includes the modulc_id, — the — siee — aftd — fehe — vcroion — ef — fehe 
module or module id and the association tag for each module. 
a modulc_id, — a oisc and a vcroion for each module — in caoc 

there — arc — a — plurality — ef — modulco, afid — fea^ information 

(referred fee hereafter as aft aoDOGiation_tag) 

identifying a module. 

[0199] After an IOR extracted from a transport stream 

is identified by the CPU 80, the following processes are 
carried out for receiving and separating objects indicated 
by the IOR. 

[0200] Prl : In the DcMUX driver 02 employed in the CPU 

80, i_. aAn ES (elementary stream) loop of a the PMT in a 

carousel is searched for an elementary stream (abbreviated 

hereafter fee aft ES-) having the same value as the 

association = tag of the IOR to obtain a PID. The ES having 
this PID includes a DII. 

[0201] Pr2 : 2 . This PID and a table— id— extension are set 

in the demultiplexer 70 as a filter condition. Under this 
condition, the demultiplexer 70 then separates the DII and 
outputs it to the CPU 80. 

[0202] Pr3 : 3 . In the DII, an association-tag of a 

module indicated by a module = id included in the 
aforementioned IOR is set. 
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[0203] Pr4 : 4 . The ES loop (the carouocl) — of the PMT is 

searched for an ES having the same value as the 
association = tag described above and a PID is obtained. The 
target module is included in an ES having this PID. 
[0204] Pr5 : 5 . The demultiplexer 70 carries out 

filtering with using the PID and the module = id set — as a 
filter condition. A transport packet separated and extracted 
in accordance with this filter condition is stored in a 
proper memory area (an array) in the queue 71 to eventually 
form a target module eventually . 

[0205] Pr 6 : An 6 . A target object corresponding to an 

object = key included in the aforementioned IOR is taken out 
from thio the target module. Thio object io the target object. 
The target object extracted from the module is written into 
a predetermined area of the DSM-CC buffer 91. 

[0206] Typically, the above operation is carried out 

repeatedly to collect target objects and store them in the 
DSM-CC buffer 91. In this way, an MHEG content for creating 
a required scene is obtained. 

[0207] TheA man-machine interface 61 receives a command 

signal transmitted by t^tea remote controller 64, supplying 
the signal to the CPU 80. The CPU 80 then carries out 

necessary control processing se as to accomplish an 

apparatus operation according to the command signal received 
from the man-machine interface 61. 

[0208] An IC card 65 is inserted into the IC card slot 
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62. The CPU 80 writes and reads out information into and 
from the IC card 65. 

[0209] Connect cd The modem 63 is connected to the 

accounting server 5 by a telephone line 4-? — tho modem 63 io 4 
and controlled by the CPU 80 to allow the IRD 12 to 
communicate with the accounting server 5. 

[0210] The following description complementarily 

explains the flow of a signal serving as a video/audio 
source in the IRD 12 with reference to the display format 
explained earlier by referring to Figs. 4A and 4B. 
[0211] In processing to output an ordinary program 

shown in Fig. 4A, MPEG video data and MPEG audio data 
required for the program are extracted from an input 
transport stream and then subjected to their respective 
decoding processes. Subsequently, the MPEG video data and 
the MPEG audio data are output to the analog video output 
terminal T2 and the analog audio output terminal T3 
respectively to have the monitor unit 14 display a picture 
and generate sounds of the broadcast program. 

[0212] In processing to output a GUI screen shown in 

Fig. 4B, on the other hand, data of an MHEG content required 
for the GUI screen (or a scene) is separated and extracted 
by a transport unit 53 from an input transport stream and 
supplied to the DSM-CC buffer 91. Then, the DSM-CC decoder 
block 83 and the MHEG decoder block 84 function to create 
picture data of the scene (the GUI screen) in the MHEG 
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buffer 92 by using the extracted data. Subsequently, the 
picture data is supplied to the analog video output terminal 
T2 by way of a display processing unit 58 to display the GUI 
screen on the monitor unit 14. 

[0213] Assume that a piece of music is selected from 

the musical list 21B displayed on the GUI screen shown in 
Fig. 4B and the audio data of the selected music is listened 
to by the user on a trial basis. In this case, the MPEG 
audio data of the selected music is generated by the 
demultiplexer 70. The MPEG audio data is then output to the 
monitor unit 14 as an analog audio signal by way of an MPEG 
audio decoder 54, a D/A converter 56, a switch circuit 57 
and the analog audio output terminal T3 . 

[0214] Assume that the download button 28 displayed on 

the GUI screen shown in Fig. 4B is pressed to download 
musical audio data. In this case, the musical audio data to 
be downloaded is extracted by the demultiplexer 70 and 
supplied to the analog audio output terminal T4 , the optical 
digital output interface 59 or the IEEE1394 interface 60. 
[0215] Assume that an MD recorder/player 13A of Fig. 12 

conforming to the IEEE1394 specifications is connected to 
the IEEE1394 interface 60. In this particular case, the 
demultiplexer 70 extracts quadruple -speed ATRAC data of the 
downloaded music and outputs the data to the IEEE1394 
interface 60 to be recorded onto a disc mounted on the MD 
recorder/player 13A. At the same time, the demultiplexer 70 
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also extracts still picture data of the album jacket and 
text data such as the lyrics and the profile of an artist 
from the transport stream, and supplies the data to the MD 
recorder/player 13A by way of the IEEE1394 interface 60. It 
should be noted that the data in the transport stream has 
been compressed in accordance with typically the JPEG system 
The still picture data and the text data are recorded into a 
predetermined area in a disc mounted on the MD 
recorder/player 13A. 



2 Authoring System 

2-1 Structure of MHEG Content 

[0216] Next, an MHEG authoring system provided by this 

embodiment is explained. 

[0217] In the case of Fig. 5, the MHEG authoring system 

of this embodiment explained below corresponds to the GUI 
authoring system 42. It should be noted, however, that since 
a personal computer is actually used for creating or 
obtaining GUI material data (such as a text file or a 
picture used as an object) in order to carry out authoring 
work, functionally, the GUI material cataloging system 34 
and the GUI material data base 38 can be considered to be 
aloo included in addition to the GUI authoring system 42. 

[0218] Figs. 13 and 14 are diagrams conceptually 

showing the structure of an MHEG content created by the MHEG 
authoring system provided by this embodiment . 
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[0219] To be more specific, Fig. 13 is a diagram 

showing 3 scenes, namely, MHEG scene 1 to MHEG scene 3. Each 
of the scenes is formed as a combination of objects pasted 
on a picture area with a size of typically ione picture. 
[0220] It should be noted that an MHEG scene is a scene 

conforming to the MHEG system. In this specification, a 
scene is referred to as an MHEG scene in some cases in order 
to distinguish it from a shared scene to be described later. 
Conversely speaking, in the following description, by a 
scene, an MHEG scene is meant. 

[0221] As described earlier, an object is interpreted 

as, among other things, picture information such as a JPEG 
or GIF still-picture file, text information, a part picture 
file such as an operation button and an audio data file. In 
the case of this embodiment, the monitor display is switched 
from one scene to another in synchronization with typically 
a TV broadcast or switched by an operation of the switch 
button. In this embodiment, switching of the monitor display 
from one scene to another is referred to as a transition. 
[0222] Assume for example that the 3 scenes, namely 

MHEG scene 1 to MHEG scene 3, are related to each other in 
accordance with a consistent relation such as a relation 
allowing a transition to occur between any two of them. The 
relation among them is arranged into a scenario unit (or 
MHEG application unit) . 

[0223] The scenario used in this case has a meaning 
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different from a description file used as a script. That is 
to say, a scenario implies a content unit at a hierarchical 
layer of an MHEG application. Provided typically with piocco x 
e£ — information ouch ao — a datatype, — a — cuotmigcd_inf o and a 
occnc_numbcr — in addition — fee — information — called — aft — co_nam e 
rcprcocnting the name of an elementary otrcam to which the 
prcocnt — occnario — is — output , — aA scenario unit is typically 
provided with pieces of information such as a data type, 
customized info, a scene number and information called an ES 
name, which is the name of the elementary stream to which 
the present scenario is output, and is formed to include 1 
or more MHEG scenes. It should be noted that the datatype 
is the data type of the present scenario. An example of the 
data type is "mheg" . The customized = inf o is customized 
information and the scene-number is the number of scenes 
included in the scenario. 

[0224] A set of scenarios which are each an arrangement 

of scenes forms an MHEG content as shown in Fig. 14. 

[0225] In an example shown in the figure, the MHEG 

content comprises 3 scenarios, namely, scenarios SCI, SC2 
and SC3 . Scenario SCI comprises 3 scenes, namely, scenes 1, 
2 and 3 . The remaining scenarios SC2 and SC3 comprise MHEG 
scenes 4 and 5 respectively. 

[0226] As shown in Fig. 13, objects are used for 

creating a scene. According to MHEG specifications, a shared 
object can also be used. 
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[0227] A shared object is an object that can be used by 

being shared among a plurality of scenes forming an MHEG 
application. 

[0228] An example of shared objects is shown in Fig. 15. 

As shown in the figure, 1 MHEG application comprises 2 
scenes, namely, MHEG scenes 1 and 2. The MHEG content 
includes 6 prepared objects, namely, objects 1 to 3 and 4 to 
6 in addition to 3 shared objects, namely, shared objects 1 
to 3 . 

[0229] Objects 1 to 3 are used for creating only MHEG 

scene 1 while objects 4 to 6 are used for creating only MHEG 
scene 2 . 

[0230] On the other hand, shared objects 1 to 3 are 

each an object that can be set as an object usable and 
sharable by both MHEG scenes 1 and 2 . 

[0231] Thus, in the case of the example shown in Fig. 

15, MHEG scene 1 can be created by using objects 1 to 3 and 
shared objects 1 to 3 while MHEG scene 2 can be created by 
using objects 4 to 6 and shared objects 1 to 3 . 

[0232] As explained earlier in the description of the 

conventional apparatus, the interface of the contemporary 
MHEG authoring tool allows the user to carry out only 
editing work of setting a flag indicating whether or not a 
shared object is to be used for all of a plurality of scenes 
constituting an MHEG application even if a shared object can 
be set. 
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[0233] In the case of the example shown in Fig. 15, if 

shared objects 1 to 3 are set for use, for instance, it is 
possible to obtain only states in which shared objects 1 to 
3 are always used and displayed for MHEG scenes 1 and 2. If 
shared objects 1 to 3 are set for no use, on the other hand, 
it is possible to obtain only states in which shared objects 

1 to 3 are not displayed for both MHEG scenes 1 and 2. 
[0234] Conversely speaking, it is impossible to set 
usage of objects in which, for example, shared objects 1 and 

2 are selected for MHEG scene 1 whereas shared object 3 is 
selected for MHEG scene 2 . In an attempt to carry out 
editing work using a shared object with a high degree of 
freedom,. it becomes necessary to write a script for 
controlling the shared objects themselves. For this reason, 
the editor must be proficient in the script language as has 
been described earlier. 

[0235] As will be described below, the MHEG authoring 

tool provided by this embodiment is configured to provide a 
simple interface which can be used by anybody but allows a 
shared object to be set for a scene with a high degree of 
freedom. 

2-2 Concept of a Shared Scene 

[0236] ^ — edit — proccooing A shared scene is prescribed 
in the editing process based on an internal format of the 
MHEG authoring tool provided by this embodiment . - — a oharod 
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occnc — io prcocribod. 

[0237] A shared scene is a virtual scene which is 

created by using one or more arbitrary objects. A shared 
scene is handled as a layer-like edit material to be used or 
displayed by superposition on a prepared MHEG scene. In 
addition, a shared scene is used by being shared among MHEG 
scenes forming one MHEG application. 

[0238] Figs. 16A to 16F are explanatory diagrams 

showing the concept of a basic edit ing operation using 
shared scenes. 

[0239] Assume that shared scenes 1 and 2 shown in Figs. 

16A and 16B have been created and prepared by using the MHEG 
authoring tool provided by this embodiment. In this case, 
shared scene 1 is created into a state in which object obi 
is displayed at a position shown in the figure. Object obi 
uQcd shown in shared scene 1 is a part ial picture of an 
operation button marked with "Next". On the other hand, 
shared scene 2 is created into a state in which object ob2 
is displayed at a position shown in the figure. Object ob2 
uocd shown in shared scene 2 is a part partial picture of an 
operation button marked with "Return". 

[0240] It should be noted that a shared scene can be 

created by carrying out necessary editing operations using a 
material comprising a variety of objects in an environment 
of the MHEG authoring tool provided by this embodiment. 

[0241] Shared scenes 1 and 2 are set so that they can 
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be used in an MHEG content provided with 4 scenes, namely, 
MHEG scenes 1 to 4 as shown in Figs. 16C to 16F respectively. 
MHEG scenes 1 to 4 are edited to includo display the 
operation buttons "Next" and/or "Return" dioplaycd on MHEC 
occnco 1 to 4 so as to allow transitions described later to 
take place as shown in Figs. 16C to 16F. 

[0242] MHEG scene 1 shown in Fig. 16C is a scene 

serving as a base point of the transitions. That is why only 
the Next operation button is displayed thereon. MHEG screen 
1 is prescribed so that, when this Next button is operated, 
a transition from MHEG scene 1 to MHEG scene 2 takes place. 

[0243] MHEG scene 2 shown in Fig. 16D displays both the 

Next and Return operation buttons. MHEG screen 2 is 
prescribed so that, when thio the Next button is 
opcratod pressed , a transition from MHEG scene 2 to MHEG 
scene 3 takes place and, when thio the Return button is 
opcratodpressed, on the other hand, — a transition from MHEG 
scene 2 back to MHEG scene 1 takes place. 

[0244] By the same token, MHEG scene 3 shown in Fig. 

16E displays both the Next and Return operation buttons. 
MHEG screen 3 is prescribed so that, when thio the Next 
button is opcrated pressed , a transition from MHEG scene 3 to 
MHEG scene 4 takes place and, when thio the Return button is 
opcrated pressed , on the other hand, — a transition from MHEG 
scene 3 back to MHEG scene 2 takes place. 

[0245] MHEG scene 4 shown in Fig. 16F is a scene 
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serving as the last scene of the transitions. That is why 
only the Return operation button is displayed thereon. MHEG 
screen 4 is prescribed so that, when thiee Return button is 
opcratcd pressed , a transition from MHEG scene 4 back to MHEG 
scene 3 takes place. 

[0246] It should be noted that, in actuality, each of 

MHEG scenes 1 to 4 generally displays scene objects at the 
same time too. In this case, however, only objects included 
in shared scenes are displayed for the sake of explanation 
oimplicity clarity . In addition, a shared scene provided by 
this embodiment may be created in general to use a plurality 
of objects. In this example, however, shared scenes 1 and 2 
arc each created to include only 1 object aloo in order to 

make the explanation caoy fee undcrotand f or clarity of 

expression . 

[0247] As described above, MHEG scenes 1 to 4 are 

edited to include the operation buttons "Next" and/or 
"Return" so as to allow the transitions to take place. In 
order to display either or both of the operation buttons, a 
relation among MHEG scenes and shared scenes needs to be 
described. 

[0248] First of all, when MHEG scene 1 is edited, 

shared objects 1 and 2 are set at a^-ON (RUN) and OFF (STOP) 
states respectively as shown at the bottom of MHEG scene 1 
of Fig. 16C. In these states, only shared object obi is 
selected and used in MHEG scene 1. That is to say, the 
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editing work results in a state in which MHEG scene 1 
displays shared object obi but not shared object ob2 as 
shown in Fig. 16C. 

[0249] Then, when MHEG scene 2 is edited, shared 

objects obi and ob2 are both set at an ON (RUN) state as 
shown at the bottom of MHEG scene 2 of Fig. 16D. In this 
state, both shared objects obi and ob2 are selected and used 
in MHEG scene 2. That is to say, the editing work results in 
a state in which MHEG scene 2 displays both shared object 
obi and shared object ob2 as shown in Fig. 16D. By the same 
token, when MHEG scene 3 is edited, shared objects obi and 
ob2 are both set at an ON (RUN) state as shown at the bottom 
of MHEG scene 3 of Fig. 16E. In this state, both shared 
objects obi and ob2 are selected and used in MHEG scene 3. 
That is to say, the editing work results in a state in which 
MHEG scene 3 displays both shared object obi and shared 
object ob2 as shown in Fig. 16E. 

[0250] Finally, when MHEG scene 4 is edited, shared 

objects ob2 and obi are set at an — ON (RUN) and OFF (STOP) 
states respectively as shown at the bottom of MHEG scene 4 
of Fig. 16F. In these states, only shared object ob2 is 
selected and used in MHEG scene 4. That is to say, the 
editing work results in a state in which MHEG scene 4 
displays shared object ob2 but not shared object obi as 
opposed to the display of MHEG scene 1. 

[0251] As described above, a shared scene is a virtual 



62 



scene which can be used by being shared among MHEG scenes 
constituting an MHEG content. As a result, an object used 
for such a shared scene is an object used by being shared 
among MHEG scenes constituting an MHEG content. That is to 
say, an object used for such a shared scene is cxactly the 
same as a shared object defined in the MHEG specifications. 
[0252] In other words, shared objects are not 

controlled individually in this embodiment. Instead, shared 
objects are each controlled as an object included in a 
shared scene . 

[0253] If a plurality of shared scenes are used for 1 

MHEG scene in this embodiment, an order of superposition of 
the shared scenes on the MHEG scene ea^should be specified. 
As a rule, when a plurality of shared scenes are used for 1 
MHEG scene in this embodiment, the shared scenes are 
superposed on each other in a specified order e# 
aupcrpoaition to create a picture which is then placed in 
front of (on) or on the picture of the MHEG scene. 

[0254] Figs. 17A to 17D are explanatory diagrams 

showing typical displays of scenes superposed in a specified 
order . 

[0255] In the example shown in the figure, 2 shared 

scenes, namely, shared scenes 3 and 4, are prepared as shown 
in Figs. 17A and 17B respectively. Shared scene 3 is formed 
to include object ob3 of an ON button picture displayed at a 
position shown in the figure. On the other hand, shared 
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scene 4 is formed to include object ob4 of an OFF button 
picture displayed at a position shown in the figure. The 
position of object ob3 on shared scene 3 coincides with the 
position of object ob4 on shared scene 4. 

[0256] The 2 o Shared scenes 3 and 4 are both uocd — (-put 

in an ON (RUN) stated — being and shared b y the 2 — acenco, 
namely, MHEG scenes 1 and 2. Fig. 17C is a diagram showing 
MHEG scene 1 using the 2 oharcd acenco, — namely shared scenes 
3 and 4. On the other hand, Fig. 17D is a diagram showing 
MHEG scene 2 using also the 2 shared scenes, namely shared 
scenes 3 and 4 . 

[0257] As shown at the bottom of Fig. 17C, in the order 

of superposition of shared scenes 3 and 4, shared scenes 3 
and 4 are superposed on MHEG scene 1 with shared scene 3 put 
at the front end and shared scene 4 put at the rear end. 

[0258] As a result, only object ob3 representing the ON 

button picture is visible on MHEG scene 1 as shown in Fig. 
17C. On the other hand, object ob4 representing the OFF 
button picture is concealed behind object ob3 and, hence, 
invisible . 

[0259] Thus, MHEG scene 1 is a GUI screen enabling only 

afl^- whereby when the ON operation to turn on oomc thing button 
is pressed . That io to a ay, — MHEG occno 1 io preocribed ao 
the GUI — screen whereby, — when thio ON button io operated to 
turn on oomc thing, a transition takes place to replace MHEG 
scene 1 by MHEG scene 2 . 
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[0260] In the case of MHEG scene 2, on the other hand, 

in the order of superposition of shared scenes 3 and 4, 
shared scenes 3 and 4 are superposed on MHEG scene 2 with 
shared scene 4 put at the front end and shared scene 3 put 
at the rear end as shown at the bottom of Fig. 17D. 
[0261] As a result, only object ob4 representing the 

OFF button picture is visible on MHEG scene 2 as shown in 
Fig. 17D. On the other hand, object ob3 representing the ON 
button picture is concealed behind object ob4 and, hence, 
invisible . 

[0262] Thus, MHEG scene 2 is a GUI screen enabling only 

aft — whereby when the OFF operation — fee — turn — e#£ — something 
which — ha-s — been — turned button is pressed eft — by uoing MI I EG 

scene 1 deocribed earlier. That io to oay, — MHEG occne 2 io 

prescribed as — the GUI — ocrccn whereby, — when thio OFF button 
io operated to turn off oomething, — a transition takes place 
to replace MHEG scene 2 by MHEG scene 1. 

[0263] Thus, when the user looks at the real GUI screen, 

the screen is switched from a display of the ON button 
picture to a display of the OFF button picture or vice versa 
each time the ON or OFF button is operated respectively. 

[0264] As described above, shared objects are handled 

in the MHEG authoring tool provided by this embodiment in a 
configuration wherein the shared objects are controlled by 
shared scenes. Thus, by setting whether or not to use a 
shared scene in an MHEG scene as described by referring to 
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Figs. 16A to 16F, shared objects for each MHEG scene can be 
selected for use in the MHEG scene. In addition, by 
specifying an order of superposition of shared scenes as 
described earlier by referring to Figs. 17A to 17D, it is 
possible to provide an editing effect wherein, while shared 
objects are used by being shared among a plurality of MHEG 
scenes, the display is capable of transiting from one scene 
to another. 

[0265] In an attempt to carry out editing work for 

displays of objects like ones shown in Figs. 16C to 16F 
given earlier in an authoring tool without introducing the 
concept of a shared scene, for example, first of all, it is 
necessary to set objects obi and ob2 each as a shared object 
and, then, to describe a script prescribing that objects obi 
and ob2 are properly placed at positions in MHEG scenes 1 to 
4 as shown in Figs. 16C to 16F respectively. 

[0266] The editing work shown in Figs. 17A to 17D is 

carried out in a similar way. That is to say, first of all, 
objects ob3 and ob4 are each prescribed as a shared object. 
Then, it is necessary to prescribe a script including an 
order of superposition of shared objects ob3 and ob4 for 
MHEG scene 1 so as to give a display state like the one 
shown in Fig. 17C. By the same token, it is necessary to 
prescribe a script including an order of superposition of 
shared objects ob3 and ob4 for MHEG scene 2 so as to give a 
display state like the one shown in Fig. 17D. 
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[0267] In order to carry out such editing work, it is 

necessary for the editor to have sufficient knowledge of a 
script language that enables the editor to do editing work 
of shared objects. Thus, a result of the editing work much 
relies on the skill owned by the editor. For this reason, 
the editor is capable of creating only a simple scene using 
shared objects due to, for example, the fact that the editor 
is capable of describing only a very simple script. In 
another case, a script is described incorrectly due to the 
fact that the editor is not well — familiar with the script 
language . An incorrect dcocription moot likely bringo about 
a bad effect of wrong reflection of — the editor' o — intention 
in the rcoult of editing. 

[0268] That ia to aay, — in the end, — the c on t cmp o r a ry The 

present authoring tools haa only a function to — turn on and 
e#f— have the functionality of turning a shared object on and 
off s imul t aneous ly for all scenes -. Thus it is making — it 
difficult to utilize a shared object effectively. 

[0269] In the case of this embodiment, on the other 

hand, the editor carries out editing work by, first of all, 
creating a shared scene using selected objects the — editor 
wanto to uac each as a shared object and- — then , creating an 
image obtained as a result of superposition of the shared 
scene on an MHEG scene. As a result, the editing work 4r& 
clooc to work of — creating creates a visual image which can 
be carried out with ease. 
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2-3 Configuration of the MHEG Authoring System 
[0270] Next, the configuration of an MHEG authoring 

system provided by this embodiment is explained. 
[0271] As described above, the MHEG authoring system 

provided by this embodiment is capable of editing MHEG 
contents defining shared scenes. However, processing carried 
out by the MHEG authoring tool including the editing work 
using such a shared scene can be conceptually configured 
into a typical eae- MHEG authoring tool as shown in Figs. 18A 
and 18B. 

[0272] Processing carried out by the MHEG authoring 

tool is classified into 2 large categories, namely, editing 
work shown in Fig. 18A and conversion work shown in Fig. 18B. 
The editing work is proccooing — carried out in accordance 
with an internal format in this MHEG authoring tool to 
create an MHEG application file or an MHEG content. On the 
other hand, the conversion work is carried out to convert an 
MHEG content created by the editing work carried out in 
accordance with the internal format in this MHEG authoring 
tool into data of the so-called MHEG- IS format conforming to 
the actual MHEG specifications. 

[0273] The MHEG- IS format is the format of an MHEG 

content with substances conforming to MHEG specifications. 
In this case, the MHEG- IS format is a format for outputting 
contents for data broadcasting. 
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[0274] That is to say, the MHEG authoring tool provided 

by this embodiment has a configuration wherein editing 
processing is carried out in accordance with an internal 
format in the MHEG authoring tool, shared scenes and the 
like which do not exist in the actual MHEG specifications 
are defined and editing processing using the defined shared 
scenes and the like can be implemented. Conversely speaking, 
operations can be typically carried out in a GUI -like 
interface so as to allow the editor to perform advanced 
editing by carrying out simpler operations without the need 
for doing sophisticated work such as writing a script 
conforming to the MHEG specifications. 

[0275] It should be noted, however, that aa edit 

aubotancc the substance of an edit of an MHEG content (that 
is, a description such as a definition statement) conforming 
to the internal format of the MHEG authoring tool is valid 
only in the MHEG authoring tool. Thus, in order to allow the 
contents of at he description conforming to the internal 
format to be decoded and displayed on the receiver side, it 
is necessary to convert the contents of the description into 
a description with contents conforming to the MHEG 
specifications. That io to gay, the Thus, the configuration 
of MHEG authoring tool is designed into a configuration in 
which contents — e#— to such that the description created by 
the edit processing according to the internal format as 
shown in Fig. 18A a^eis converted into a description with 
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contents conforming to the MHEG-IS format by the conversion 
processing shown in Fig. 18B. 

[0276] ^he Using the above description as a basis, the 

following detailed description again explains the concept of 
processing in the MHEG authoring tool provided by this 
embodiment to do editing work using shared scenes with 

reference to Figs. 18A and 18B aad^ with fefee above 

description uocd ao a prcmiQC 

[0277] As shown in Fig. 18A, in the MHEG authoring tool, 

editing work is carried out on ian MHEG content comprising 2 
scenes, namely, MHEG scene 1 and MHEG scene 2. 3 -Three files, 
namely, shared-object files 1, 2 and 3 are created and 
prepared each as a shared object that can be used by MHEG 
scene 1 and MHEG scene 2. Shared-object file 1 is created by 
using objects 1 and 2 whereas shared-object file 2 is 
created by using objects 3 and 4. As for creation of shared- 
object file 3, objects 5 and 6 are used. 

[0278] Here, assume that the editor edits scenes in an 

environment of the MHEG authoring tool. In this case, MHEG 
scene 1 is edited by using shared-scene files 1 and 2 to 
produce its desired display format whereas MHEG scene 2 is 
edited by using a shared-scene file 3 to produce its desired 
display format. 

[0279] Then, in the MHEG authoring tool, a shared-scene 

definition statement 1 of shared-scene files 1 and 2 is 
formed as "authoring control information" in accordance with 
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actual results of the editing for MHEG scene 1 whereas a 
shared-scene definition statement 2 of shared-scene file 3 
is formed as other "authoring control information" in 
accordance with the actual results of the editing for MHEG 
scene 2 . 

[0280] Here, the concept of a shared scene is 

prescribed in the MHEG authoring tool provided by this 
embodiment. However, the prescription itself is not included 
in the brief description of the MHEG - IS format. On the other 
hand, the MHEG- IS system prescribes a description format 
indicating how individual shared objects are used for each 
MHEG scene . 

[0281] For this reason, in the processing to output a 

result of editing by using a shared scene in the MHEG 
authoring tool provided by this embodiment as described 
above, that is, the processing to output a description of 
authoring control information (or shared-scene definition 
statements) in the MHEG- IS format, it is necessary to 
convert the description into description contents of a 

script (or control information) used in execution e# 

executing control iftof individual shared-object units in 
accordance with the MHEG description outline. 

[0282] Thus, in the MHEG authoring tool provided by 

this embodiment, the description is converted into an output 
with the MHEG- IS format as shown in Fig. 18B. 

[0283] In this conversion, first of all, objects 1 to 6 
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used in shared-scene files 1, 2 and 3 as shown in the left- 
hand- side diagram of Fig. 18B are prescribed in an MHEG 
content (or an MHEG application file) as shared objects 1 to 
6 and controlled as a set of shared objects. 

[0284] Then, for MHEG scene 1, a link for controlling 

shared objects 1 to 4 is described in a description file 
which is provided to the MHEG application file as shown in 
the right -hand-side diagram of Fig. 18B. 

[0285] By the same token, for MHEG scene 2, a link for 

controlling shared objects 5 and 6 is described in a 
description file which is provided to the MHEG application 
file. 

[0286] Then, the MHEG application file converted into 

the MHEG- IS format as described above is output as a content 
for a data broadcast multiplexed in a digital satellite 
broadcast. If the configuration of the ground station 1 
shown in Fig. 5 is taken as an example, the MHEG application 
file converted into the MHEG- IS format is data output from 
the MHEG authoring tool 42 to the DSM-CC encoder 44. 

[0287] In the reception facility 3, for example, the 

digital satellite broadcast with the content for a data 
broadcast multiplexed therein is received by the IRD 12 and 
subjected to processing such as an MHEG decoding process in 
the CPU 80 so as to allow the display of a GUI screen to be 
controlled in accordance with the MHEG system. 

[0288] Let t The MHEG contents of the MHEG scenes shown 
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in Figs. 16A to 16F b eare edited in proccooing carried out 
by using the MHEG authoring tool shown in Figs. 18A and 18B 
an d fee— broadcasted as a data broadcast. In this case, the 
IRD 12 outputs and displays an MHEG picture in display 
formats li3cc the onco as shown in Figs. 16C to 16F. 
[0289] Fig. 19 is a diagram showing a typical actual 

configuration of the MHEG authoring tool provided by this 
embodiment . 

[0290] In actuality, the MHEG authoring tool 42 

typically comprises a personal computer 201 and MHEG 
authoring software 210 activated in the personal computer 
201 . 

[0291] As shown in the figure, the personal computer 

201 of the MHEG authoring tool 42 physically includes 
hardware 2 02. 

[0292] The hardware 202 comprises a CPU (Central 

Processing Unit) 202a, a RAM (Random-Access Memory) 202b, a 
ROM 202c and an interface 202d. The CPU 202a executes 
various kinds of control and carries out a variety of 
operations. The RAM 202b is used for storing information 
such as an application program executed by the CPU 202a and 
data generated as a result of processing carried out by the 
CPU 202a. The ROM 202c is used for storing information 
required for operations of the personal computer 201. The 
interface 202d is provided for facilitating exchanges of 
information between the hardware 2 02 and external equipment 
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and external operation units to be described later. 
[0293] It should be noted that the hardware 202 may 

include a variety of other devices. 

[0294] A basic program is executed on this hardware 202 

as an operating system 203 to provide an environment that 
allows MHEG authoring software of this embodiment to be 
executed . 

[0295] The external equipment and the external 

operation units connected to the personal computer 2 01 shown 
in the figure include a display unit 221, a mouse 222, a 
keyboard 223, a speaker 224, a storage device 225 and a 
video unit 226. 

[0296] The display unit 221 displays a picture output 

by the personal computer 201. GpGciall y Specif ically , in fefee 
caoc of this embodiment, a GUI screen for editing work using 
the MHEG authoring software 210 to be described later is 
also displayed, 

[0297] The mouse 222 and the keyboard 223 each serve as 

an operator unit used by the editor for entering operation 
information to the personal computer 201. 

[0298] The speaker 224 is provided for outputting an 

audio signal generated by the personal computer 201 to the 
outside . 

[0299] The storage device 225 is — used — £e*? — storing 

stores information required by the personal computer 201. 
Examples of such information are the operating system 2 03 
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and predetermined application software ouch ao including the 
MHEG authoring software 210 provided by this embodiment. In 
the case of this embodiment, the stored information also 
includes MHEG contents themselves and objects used for 
forming each of the MHEG contents such as picture files, 
sound files and text files. The MHEG authoring software 210 
is executed to create files of these objects to be stored in 
the storage device 2 25 and to carry out editing work by 
using the files of these objects. 

[0300] It should be noted that, ao the atoragc device 

225, — it is desirable to use a storage unit capable of 

accommodating a relatively large amount of data as the 

storage device 225, for example, ^ A good example of ouch a 

otoragc — unit — is- a hard-disc drive. However, — fefee — atoragc 
device 225 doco not have to be a hard dice drive. 

[0301] A typical video unit 226 is a VTR which is 

capable of recording and playing back video information onto 
and from a video tape or a video disc. 

[0302] An example of an MHEG content is a scene change 

synchronized with a broadcast program comprising pictures 
and sounds. In processing to edit an MHEG content 
synchronized with such a broadcast program, the video unit 
226 can be used typically for playing back the broadcast 
program comprising pictures and sounds. 

[0303] Next, the MHEG authoring software 210 is 

explained . 



[0304] As described earlier, the MHEG authoring 

software 210 is an application software operating on the 
personal computer 201. The program is stored in the storage 
device 225. 

[0305] After being read out from the storage device 225 

for activation as a program, the MHEG authoring software 210 
can be represented as functional blocks shown in the figure. 

[0306] It should be noted that, even though the figure 

dees — net — explicitly — ohowa — rolationo — among — fefee — functional 
blocko of the MHEG authoring ooftwarc 210, — in actuality, the 
MHEG authoring software 210 has a configuration (not shown) 
in which information is exchanged between the functional 
blocks 96 — sts — to allowe required functions of the MHEG 
authoring software 210 to be executed. 

[0307] In the MHEG authoring software 210, an object 

creation module 211 is a functional block comprising 
programs used for creating a file used as an object. For 
example, the editor 4rS — capable — ef — creating — may use the 
keyboard 223, the mouse 222 and other components in 
conjunction with the programs of the object creation module 
211 or a GUI screen displayed on the display unit 221 to 
create a file used as an object^ by uoing the keyboard 223, 
the mouoc — 2-2-2 — and other componcnto — in conjunction with the 
programo — of — the — obj cot — creation module — 2ii — or a GUI — ocrccn 
dioplaycd on the dioplay unit 221. If the object created is 
a picture, for example, the editor is capable of creating 
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the object by rendering a picture file using functions of 
the object creation module 211. In addition to a picture 
file, according to the prescription, the created object may 
be a text file or a sound file. In this case, of course, the 
object creation module 211 can be used for forming a text or 
sound file. An object file created by using the object 
creation module 211 can be stored and retained in the 
storage device 225. 

[0308] A shared-scene creation module 212 comprises 

programs for creating a shared scene by utilizing object 
files created by using the object creation module 211. 
[0309] In this case, for example, the editor is capable 

of creating any arbitrary number of shared scenes as long as 
the number is smaller than an upper limit prescribed by the 
MHEG authoring software 210. Much like an object file, a 
shared scene is created by operating the keyboard 223, the 
mouse 222 and other components which are used in conjunction 
with the programs of the shared-scene creation unit 212 to 
select any arbitrary number of object files created so far. 
[0310] An MHEG- scene creation module 213 is a 

functional block comprising programs used for creating an 
MHEG scene. The programs of the MHEG- scene creation module 
213 are used for selecting an object file created by using 
the object creation module 211 and the selected object file 
is used for creating an MHEG scene. 

[0311] Programs of a shared-scene processing module 216 
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are executed to perform processing to edit a relation 
between an MHEG scene and a shared scene in accordance with 
an operation carried out by the editor for the GUI screen 
thereof. To put it in dotail Specif ically , the shared-scene 
processing module 216 is programo for carrying out programmed 
for editing work such as setting a shared scene on an MHEG 
scene as shown in Figs. 16A to 16F and specifying an order 
of superposing a plurality of shared scenes to be used on an 
MHEG scene as shown in Figs. 17A to 17D. 
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[0313] [0312] Details of an MHEG content creation module 

214 are not explained. Briefly speaking, the MHEG content 
creation module 214 is used for creating a scenario 
explained earlier by referring to Fig. 14 in accordance with 
a result of editing predetermined contents of typically a 
scene . 

[0314] [0313] The MHEG-applicat ion creation module 215 

integrates results of editing work carried out by using the 
object creation module 211, the shared-scene creation module 
212, the MHEG- scene creation module 213, the MHEG content 
creation module 214 and the shared-scene processing module 
216 described so far to create an MHEG-application file (or 
an MHEG content) controlled in accordance with an internal 
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format. In order to implement this function, in the MHEG- 
application creation module 215 provided by this embodiment, 
a description file containing "authoring control 
information" also shown earlier in Fig. 18A is generated and 
aftthe MHEG contents is controlled in accordance with the 
internal format. Here, the authoring control information 
also includes a shared-scene definition statement created on 
the basis of an editing result produced by the shared-scene 
processing module 216 and a description file of a scenario 
created by using the MHEG content creation module 214. In 
addition, transitions among scenes can also be controlled in 
accordance with the internal format by using the authoring 
control information described by using the MHEG -application 
creation module 215. 

[0315] [0314] Furthermore, in the caoc of an edited MHEG 

nnnt-.nnf. for accompl iohincr owitching control information for 
the synchronization of a scene output in oynohroni sat i on 
with a the broadcasting time of a broadcast program-; — control 
information — — fe-he — synchroni sat ion is also described as 
authoring control information. When the authoring control 
information is converted into a dcocription in the MHEG- IS 
format — as — wiii — be — deocribed — later , the contents of the 
description of the control information for synchronization 
jrs— are also converted and output ao well . 

[0316] [0315] Information obtained as an MHEG content 

created by using the MHEG-application creation module 215 as 
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described above is handled in accordance with an internal 
format by the MHEG authoring software as explained earlier 
by referring to Figs. 18A and 18B. 

[0317] [0316] Then, in this embodiment, an MHEG 

application file created in accordance with the internal 
format can be output to the external by processing carried 
out by an internal -format -file output control module 217 as 
an internal -format file with the internal format remaining 
unchanged as it is. 

[0318] [0317] For example, an internal -format file of an 

MHEG application output by the internal -format- file output 
control module 217 can be stored and retained in the storage 
device 225. By doing so, the internal - format file stored in 
the storage device 225 can be transferred later to the 
personal computer 201 which is capable of changing editing 
contents by execution of the MHEG authoring software 210. 

[0319] [0318] An MHEG-script output control module 218 

receives data of an MHEG-application file created by the 
MHEG-application creation module 215 in the internal format^ 
and converts the data into a description of a script (or 
control information) conforming to the actual MHEG 
specifications and outputs , outputting the description to 
the external. That is to say, the MHEG-script output control 
module 218 outputs a regular MHEG (MHEG- IS ) application file. 

[0320] [0319] Typically, the output of the MHEG-script 

output control module 218 is supplied to the DSM-CC encoder 
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44 shown in Fig. 5. 

[0321] [0320] It should be noted that an MHEG 

application file of the MHEG- IS format produced by the MHEG- 
script output control module 218 can be stored and retained 
in the storage device 225. In actuality, an application file 
of the MHEG- IS format stored and retained in the storage 
device 225 is supplied to the DSM-CC encoder 44 employed in 
the ground station 1 when required. 

[0322] [0321] ^ #In comprising the configuration of the 

MHEG authoring software explained so far is — compared with 
the processing shown in Figs. 18A and 18B, the functional 
circuit blocks of the software correspond to the processing 
according to the internal format of the MHEG authoring tool 
shown in Fig. 18A. As described earlier, the functional 
circuit blocks are the object creation module 211, the 
shared- scene creation module 212, the MHEG scene creation 
module 213, the MHEG content creation module 214, the MHEG 
application creation module 215, the shared-scene processing 
module 216 and the internal -format file output control 
module 217. 

[0323] [0322] In addition, the object creation module 

211 corresponds to the processing shown in Fig. 18B to 
convert MHEG application information expressed in the 
internal format into an MHEG- IS output. 

2-4 Typical GUI Screens Displayed as Part of MHEG Authoring 
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Software 

[0324] [0323] As described above, the MHEG authoring 

software 210 provided by this embodiment is application 
software running on the personal computer 201. The MHEG 
authoring software 210 is also capable of carrying out fehe 
do called command- line editing typically for describing a 
script conforming to the MHEG specifications. In order to 
allow a variety of editing operations to be carried out as 
visually as possible, mainly including mainly the editing of 
a shared scene described earlier — fee — be — carried — e«fe — as 
vioually as poaoiblo , the MHEG authoring software 210 has an 
operation style embracing the GUI. That is to say, much like 
various kinds of software developed in recent years for 
personal computers, the MHEG authoring software 210 allows 
the editor to carry out editing operations by operating the 
mouse 22 2 and the keyboard 223 while looking at an operation 
screen appearing on the display unit 212. 

[0325] [0324] It should be noted that an operation on an 

interface such as the GUI can be implemented with ease by 
typically carrying out edit processing according to the 
internal format in the MHEG authoring software 210 as 
described earlier. 

[0326] [0325] Figs. 20A and 20B are diagrams showing a 

typical display format of a GUI screen for editing 
operations carried out by using the MHEG authoring software 
210 provided by this embodiment. In particular, the figure 
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shows a GUI screen related to shared-scene editing which is 
a characteristic of this embodiment. 

[0327] [0326] In particular, Fig. 20A is a diagram 

showing a typical basic display format of a GUI screen for 
creating an MHEG application file. The picture of the GUI 
screen is displayed typically on the display unit 221. 

[0328] [0327] As shown in Fig. 20A, the screen displays 

an MHEG application window WD1 and a shared-scene control 
window WD2 . 

[0329] [0328] The MHEG application window WD1 is a 

window for visually displaying the structure of an MHEG 
application created by the editor. For example, the window 
has a title of "MHEG Application". 

[0330] [0329] In the first place, on the left side of 

the MHEG application window WD1 , a column with a title of 
"Scene" is displayed for presenting a list of MHEG scenes 
constituting this MHEG application. In this example, the 
scene column displays 5 MHEG scenes, namely MHEG scenes 1 to 
5 . 

[0331] [0330] It should be noted that, in case there are 

too many MHEG scenes constituting ithe MHEG application so 
that all the MHEG scenes can not be accommodated in the 
display area of the MHEG application window WD1, the MHEG 
application window WD1 can be displayed^ for example^ in a 
format that allows the window to be scrolled. 

[0332] [0331] In the second place, on the right side of 
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the MHEG application window WD1, a column with a title of 
"Shared-Scene Setting Status" is displayed for visually 
displaying the present setting status of the MHEG scenes. 
The setting status of an MHEG scene shows which shared 
scenes are used and, if a plurality of shared scenes are in 
use, the status specifies what order the shared scenes are 
to be superposed in. 

[0333] [0332] On the "Shared-Scene Setting Status" 

column, 1 shared scene is expressed by an icon which is 
referred to as a shared-scene icon Ish. A shared-scene icon 
Ish is denoted by notation shsN where N is a natural number, 
that is, a positive integer- — The variable N io denoting the 
number of a file of the shared scene. 

[0334] [0333] Take MHEG scene 1 as an example. In this 

case, the status shows that only one shared-scene icon Ish 
marked with "shsl" is displayed to indicate that only shared 
scene 1 is used to create MHEG scene 1. Likewise, in the 
case of MHEG scene 2, only shared scene 1 is used to create 
MHEG scene 2 . 

[0335] [0334] Similarly, in the case of MHEG scene 4, 

the status shows that only one shared- scene icon Ish marked 
with "shs2" is displayed to indicate that only shared scene 
2 is used to create MHEG scene 4. By the same token, in the 
case of MHEG scene 5, the status shows that only one shared- 
scene icon Ish marked with "shs6" is displayed to indicate 
that only shared scene 6 is used to create MHEG scene 5. 
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[0336] [0335] In the case of MHEG scene 3, on the other 

hand, the status shows that two shared-scene icons Ish 
marked with "shsl" and "shs2" are set to indicate that two 
shared scenes 1 and 2 are used to create MHEG scene 5. The 
fact that shared scene 1 is placed first on the row to be 
followed by shared scene 2 indicates that shared scene 1 
denoted by shsl is to be displayed first on MHEG scene 3 to 
be followed by shared scene 2 denoted by shs2 . That is to 
say, the status specifies an order of superposition in which 
shared scene 1 is placed on the front side and shared scene 
2 is placed on the rear side. 

[0337] [0336] As described above, the shared-scene 

control window WD 2 is displayed on the right side e#adjacent 
the MHEG application window WD1 — at a place adjacent — to the 
MHEG application window WD1 . 

[0339] [0337] The shared-scene control window WD2 has a 

title of "Shared Scenes" to indicate that this window shows 
a list of shared scenes created and prepared by the editor. 
In this example, the shared-scene control window WD2 
presently displays 6 shared scenes, namely, shared scenes 1 
to 6. 

[0339] [0338] The shared scenes set on the "Shared-Scene 

Setting Status" column of the MHEG application window WD1 
described above for each MHEG scene are selected arbitrarily 
from the shared scenes on the list displayed on the shared- 
scene control window WD 2 . 
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[0340] [0339] There are a variety of possible operations 

to select a shared scene from the list. In an example of the 
possible operations, a shared scene arbitrarily selected 
from the list on the shared- scene control window WD 2 is 
moved to the position of a shared- scene icon for any 
arbitrary MHEG scene on the "Shared- Scene Setting Status" 
column on the MHEG application window WD1 by carrying out a 
drag-and-drop operation. 

[0341] [0340] In addition, the specification of an order 

of superposition for an MHEG scene on the "Shared-Scene 
Setting Status" column on the MHEG application window WD1 
can be changed by carrying out a drag-and-drop operation 
cited above. 

[0342] [0341] Assume for example that, with the screen 

of Fig. 20A displayed, any arbitrary one of MHEG scenes 1 to 
5 is selected by using typically a pull -down menu which is 
not shown in the figure. Then, a predetermined operation is 
carried out to call an edit screen (or a window) for the 
selected MHEG scene. Fig. 2 0B is a diagram showing a typical 
scene edit screen. 

[0343] [0342] Assume for example that the scene edit 

screen shown in Fig. 20B is a screen for MHEG scene 1. In 
this case, the scene edit screen displays the picture of 
MHEG scene 1 which uses shared scene 1. In this figure, an 
object included in shared scene 1 is shown as a hatched 
ellipse . 
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2-5 Processing Operations 

[0344] [0343] The following description explains a 

variety of processing operations carried out by a CPU 202a 
employed in the hardware 202 shown in Fig. 19 by execution 
of the MHEG authoring software 210 provided by this 
embodiment. The processing operations are exemplified by 
processing to edit a shared scene which is a characteristic 
of the embodiment . 

[ 0315] [0344] Fig. 21 is a flowchart showing processing 

operations carried out to create a shared scene. The 
operations are carried out by execution of programs of 
mainly the shared- scene creation module 212 and the MHEG- 
application creation module 215 included in the MHEG 
authoring software 210. 

[0346] [0345] As shown in the figure, the processing 

begins with a— step S101 at which a shared scene is created 
in accordance with operations carried out by the editor. 

[0347] [0346] -f-R fche dcocription given so far, ae 

explanation — ei — opcrationo fee — create — a — shared — occne is- 

included in particular. — In order to create a shared scene, a 
shared scene creation screen dioplaycd is presented as a GUI 
screen in a format like a typical one shown in Fig. 20B 4e 
prcocntcd ao a GUI . The editor then oaefeee creates a picture 
to be used as a shared scene by pasting objects selected 
arbitrarily typically from already prepared objects such as 
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picture and text files on the shared-scene creation screen 
in order to — create a picture — to bo uocd ao — a — oharcd occne 
proper for a target . 

[0348] [0347] At 4^he step S101, display control 

processing is carried out to change the appearance of the 
GUI screen in accordance with such an operation to create a 
shared scene described above. In addition, an operation to 
create a shared scene also causes information on a temporary 
shared scene to be controlled in accordance with an internal 
format . 

[0349] [0348] In this embodiment, a variety of editing 

results for an MHEG application typically including shared 
scenes are controlled in the MHEG-applicat ion creation 
module 215 by being described as authoring control 
information according to the internal format. 

-E&3-&&MQ349] Then, at a step S102, a description 

according to contents of the shared scene created at the 
step S101 is written as the authoring control information 
according to the internal format . 

[0351] [0350] Subsequently, at a— step S103, the shared 

scene created at the step S101 is controlled as a file and 
stored and retained in the storage device 225 . To put — i-fe- 

concrctcly, fefee oharcd occne is stored aad retained 

typically in the — otoragc device — 225-. It should be noted, 

however, that information contained in the stored file of 
the shared scene also conforms to the internal format. 
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[0352] [0351] The processing up to this point is carried 

out to create a certain shared scene which can be stored as 
a file conforming to the internal format. Then, this 
procedure (or processing) is carried out for each shared 
scene so as to allow shared-scene files required for 
creation of an MHEG scene to be prepared. It should be noted 
that a directory of shared- scene files stored in this way is 
controlled as authoring control information in the MHEG- 
application creation module 215. 

[0353] [0352] Fig. 22 is a diagram showing processing 

operations seto set a shared scene for an MHEG scene. The 
operations are carried out by execution of programs of 
mainly the shared-scene processing module 216 and the MHEG- 
application creation module 215. 

[0354] [0353] At a stage prior to the processing shown 

in Fig. 22, MHEG scenes and shared scenes are prepared to 
create ithe MHEG content. It should be noted that the 
creation of an MHEG scene itself is not described before. 

The creation of an MHEG scene is implemented ±a a 

configuration *a by displaying the whirefe a** MHEG- scene 

creation screen having a format like the one ohown in Fig. 

2QB — deocribed — before — — dioplayod, aad — the — editor — then 

crcatca an and having the editor create the MHEG scene on 

the screen using -. In the — creation of — an MHEG — scene, the 

MHEG- scene creation module 213 f unctiono . 

[0355] [0354] As shown in Fig. 22, the processing begins 
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with a^step S201 at which processing to set shared scenes 
for each MHEG scene is carried out in accordance with an 
operation performed by the editor. 

[0356] [0355] That is to say, in accordance with an 

operation to set shared scenes for an MHEG scene as 
described earlier, processing is carried out., for among 
other purposes, to output a GUI picture like the one shown 
in Figs. 20A and 20B as a result of editing. In the 
operation to set shared scenes for an MHEG scene, shared 
scenes to be used for the MHEG scene and an order of 
superposition of the shared scenes are specified. 

[0357] [0356] Then, when shared scenes are set for a 

certain MHEG scene as described above, the setting of the 
shared scenes for the MHEG scene is described as authoring 
control information at a— step S202. To put it concretely, a 
shared-scene definition statement explained earlier by 
referring to Figs. 18A and 18B is created. 

[035 8 ] [0357] In actuality, the processing shown in Fig. 

22 is carried out for each MHEG scene. Then, the setting of 
shared scenes for each MHEG scene obtained as a result of 
operations carried out by the editor during such processing 
is described by the MHEG-applicat ion creation module 215 as 
authoring control information. 

[0359] [0358] The piccco steps of processing shown in 

Figs. 21 and 22 are thus processing carried out by execution 
of the MHEG authoring software 210 in accordance with an 
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internal format to edit an MHEG application provided by this 
embodiment by creation of shared scenes and setting the 
shared scenes for each MHEG scene. 

[0360] [0359] It should be noted that authoring control 

information created in the piccco of proccooing steps shown 
in Figs. 21 and 22 can be stored in the storage device 225 
as information on an MHEG application according to the 
internal format along with typically a variety of files used 
mainly as objects through processing of the internal- format - 
file output control module 217. It is worth noting, however, 
that operations of the processing of the internal- format - 
file output control module 217 are not shown explicitly in 
Figs . 21 and 22 . 

[0361] [0360] _In order to output ea t he MHEG application 

conforming to the internal format as described above as a 
data content for broadcasting, that is, in order to output 
content information controlled by authoring control 
information as a broadcasting data content, it is necessary 
to convert the format of the MHEG application into an MHEG- 
IS format as has been described earlier by referring to Figs. 
18A and 18B. In the following description, description 
contents of a script conforming to the MHEG- IS format is 
referred to as an MHEG- IS script. The following description 
explains processing to convert information on an MHEG 
application from the internal format into the MHEG- IS format 
of an MHEG script with reference to Figs. 23 and 24. This 
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conversion processing is proccooing to be carried out in an 
environment where the MHEG authoring software 210 is 
executed. 

[0362] [0361] It should be noted, however, that the 

explanation of the conversion processing is limited in this 
case to a shared scene or a shared object which is a 
characteristic of this embodiment. 

[0363] [0362] In addition, the processing described 

below is carried out by executing programs of the MHEG- 
script output control module 218. 

[0364] [0363] Fig. 2 3 is a diagram showing preparatory 

processing to output a result of editing a shared scene as 
an MHEG script. Typically, after this preparatory processing 
is completed, the conversion processing shown in Fig. 24 is 
actually carried out to produce an MHEG script. 

[0365] [0364] As shown in Fig. 23, the processing begins 

with a step S301 to fetch information on an MHEG application 
described in the internal format of the MHEG authoring 

software 210. Here, £e*= — a — purpose — e# — confirmation, im 

proccooing conforming fee fefee internal format, aShared 

objects are controlled in authoring control information as 
objects forming a shared scene. 

-E0^64-[0365] Then, at a— next step S302, the contents of 

the MHEG application fetched at the step S301 are analyzed 
to acquire all shared scenes which are included in this MHEG 
application and set for use in MHEG scenes of the MHEG 
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application . 

4S3^-7M0366] Subsequently, at a^step S303, processing 

is carried out to set all the objects used in the shared 
scenes obtained at the step S302 in the MHEG application (or 
the MHEG script) as shared objects. 

[0368] [0367] To put it concretely, the following MHEG 

script is described in this processing. 

[0369] [0368] In the MHEG script, a shared object is 

defined by a description of a "Shared" parameter which 
represents an attribute of the object as follows. 

[0370] [0369] Shared = True 

indicates that the object is prescribed as a shared object. 

[0371] [0370] On the other hand, 

[0372] [0371] Shared = False 

indicates that the object is prescribed to be not a shared 
obj ect . 

[0373] [0372] Thus, at the step S303, the attribute of 

each object used in the shared scenes obtained at the step 
S302 is described as follows: 

[0374] [0373] Shared = True 

[0375] [0374] By describing the attribute in this way, 

all the objects are each treated as a shared object. 

[0376] [0375] As aAnother parameter of an object, 

Initially Active is defined-: The Initially Active parameter 

-ieas a parameter set to indicate whether the object is 
active or inactive in an initial state in an MHEG scene or 
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an MHEG application. 



[0377] [0376] 


initidiiy Active — ±xut= 


indicates that 


the object is active initially. 


[0378] [0377] 


On the other hand, 


[0379] [0378] 


Initially Active = False 


indicates that 


the object is inactive initially. 


[0380] [0379] 


Finally, at a— step S304, for 



shared objects set at the step S303, this parameter is set 
as follows. 

[0381] [0380] Initially Active = False 

That is to say, each of the shared objects is inactive 
initially. 

[0382] [0381] Next, processing shown in Fig. 24 is 

explained. 

[0383] [0382] As shown in the figure, the processing 

begins with ar-step S401 at which the preparatory processing 
explained earlier by referring to Fig. 23 is carried out. 

[0384] [0383] When the preparatory processing is 

completed, the processing flow goes on to a— step S402. 

[0385] [0384] At the step S402, a fetched MHEG 

application is examined to form a judgment ao to - determine 
whether or not one or more MHEG scenes are set and used in 
the MHEG application. Typically, the judgment is formed by 
referring to authoring control information conforming to the 
internal format . 

[0386] [0385] If the outcome of the judgment indicatco it 
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is determined that MHEG scenes to be used are not set in the 
MHEG application, no processing is specially required for 

shared Dccnco. ^scenes and -^BrS — caoc , the processing is 

ended . I f 4rfee — outcome — &€ — fcfee — j udgmcnt indicatco it is 

determined that MHEG scenes to be used are set in the MHEG 
application, on the other hand, the flow of the processing 
goes on to a— step S403. 

[0387] [0386] At the step S403, the MHEG application is 

checked to form a judgment aa to determine whether or not 
there is still an unselected MHEG scene which remains to be 
subjected to hereafter proccooing to convert a shared scene 
into a shared object. Thus, when the flow goes on from fefee 
step S402 to the step S403 for the first time, the rcoult of 
determination thc judgment formed at— fc*te step S403 certainly 
indicates that there is an MHEG scene to be subjected to 
such conversion processing. In this case, the flow of the 
processing proceeds to— a step S404. 

[0388] [0387] At — fefee step S404, one of presently set 

MHEG scenes is selected and the authoring control 
information of the selected MHEG scene is fetched as an 
object of processing. Typically, an MHEG scene is selected 
sequentially according to an MHEG-scene sequence number. 

[0389] [0388] It should be noted that MHEG scenes once 

selected before at the step S404 are no longer subjected to 
the subsequent processing. 

[0390] [0389] At the step S405, a link is described as 
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an MHEG script to indicate that all shared objects are to be 
stopped (turned off) at activation of this MHEG scene. To 
put it concretely, for all shared objects included in the 
MHEG application, an MHEG script regarding shared objects 
for this MHEG scene is described as follows: 
[0391] [0390] Initially Active = False 

[ 0392] [0391] The prescription obtained as an actual 

editing result thus indicates that, in this MHEG scene, 
shared objects are not used at all. 

[0393] [0392] At — a step S406, the authoring control 

information (or shared-scene definition statements) of the 
selected MHEG scene fetched at the step S404 is referred to 
in order to form a judgment ao to determine whether or not 
there is a shared scene set for the MHEG scene. 

[0394] [0393] If the — rcoult — enf — the — judgment — formed — 

the otcp it is determined that C40C io a negation, — that io, 
if there is no shared scene set for the MHEG scene, the flow 
of the processing goes back to the step S403. 

[0395] [0394] If tfee — rcoult — en£ — the — judgment — formed — at 

the otcp it is determined S406 indicated G 4 0C indicatca that 
there is a shared scene set for the MHEG scene, on the other 
hand, the flow of the processing goes on to— a step S407. 

[0396] [0395] At fc-he step S407, the MHEG scene is 

checked to form a — judgment — as — Re determine whether or not 
there is still an unselected shared scene which remains to 
be mihjpni-.P.ri to the following proccooing processed to convert 



96 



the shared scene into a shared object. Thus, when the flow 
goes on from the step S405 to the step S406 for the first 
time, the rcoult of — the judgment formed at — fehe it has been 
determined at step S407 certainly indicatco that there is a 
shared scene to be subjected to such conversion processing. 
In this case, the flow of the processing proceeds to-e step 
S408 . 

[0397] [0396] At the step S408, one of unselected MHEG 

scenes remaining as an object of the conversion processing 
is selected. To put it in detail, processing is carried out 
to select and fetch the description contents such as a 
shared- scene definition statement on a shared scene which 
has been opacified placed at the rearmost end. 

[0398] [0397] It should be noted that shared scenes once 

selected before at the step S408 are no longer subjected to 
the subsequent processing. 

[0399] [0398] Next, at a step S409, processing is 

carried out to describe a link as an MHEG script to run or 
turn on shared objects included in the shared scene fetched 
at the step S408 at activation of the MHEG scene fetched at 
tfee step S404 as a current processing object. In order to 
describe a link to run shared objects, typically, the 
following is described for each of the shared objects. 

[0400] [0399] If ^ initially Active = True ± 

[0101] [0400] As — a — result, — the MHEG script prescribes 

that the shared objects serving as a material of the shared 
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scene fetched at the step S408 be put in an active state at 
activation of the MHEG scene and displayed at proper 
positions on the display screen. 

[0402] [0401] As the processing of — the step S409 is 

completed, the flow goes back to the step S407. If the 
result of the judgmcnt determination formed at-^fehe step S407 
indicates that there is a shared scene to be subjected to 
such conversion processing, the flow of the processing 
proceeds to the step S408 to carry out the processing of the 
step S408 and the subsequent processing. 

[0403] [0402] The pieces of processing of the steps S407 

to S409 are carried out repeatedly for a selected and 
fetched MHEG scene as many times as the number of shared 
scenes set for the MHEG scene. 

[0401] [0403] By carrying out the — piccco — a€ — procooaing 

ef — fehe — steps S407 to S409 repeatedly, it is possible to 
obtain description contents of an MHEG script specifying 
utilization of shared objects in a certain MHEG scene in 
accordance with results of work carried out earlier by the 
editor to edit shared scenes. At the same time, it is also 
possible to obtain description contents of an MHEG script 
specifying an order of superposition of the shared objects. 

[0405] [0404] As described above, -fehe piccco e# 

procooaing — ©€ the — steps S407 to S409 are carried out 

repeatedly for an MHEG scene as many times as the numb er of 
shared scenes set for the MHEG scene. Ao the rcoult of the 
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outcome formed at the otcp C107 indicatco a negation, — When 
no more shared scenes remain, the flow of the processing 
goes back to the step S403. 

[0406] [0405] When the flow of the processing returns to 

the step S403 from the step S409 or S406 and the rcoult of 
the — it is determined in judgment — formed — at — the — step S403 
indicatca that there is an MHEG scene left as an object of 
the conversion processing, the flow goes on to the step S404 
to carry out the processing of — the step 4 04 and the 
subsequent processing . 

[0107] [0406] That — is — fee — seyr — the piccca — e£ — proceeding 

e^— Thus , the— s t ep s S403 to S409 are carried out repeatedly 
for an MHEG application file (or an MHEG content) as many 
times as the number of MHEG scenes created for the MHEG 
content . 

[0408] [0407] After the — piccco e£ proceeding — &€ the 

steps S403 to S409 have been carried out — repeatedly for an 
MHEG contcnt completed, ao many timca ao MHEG ocenco created 
for the MHEG content, — the outcome of the judgment formed at 

the step S403 indicates a negation. In thio cage, that the 

processing is ended. 

[0409] [0408] In this way, at the stage the processing 

carried out so far is ended, an internal - format result of 
editing work performed by using the MHEG authoring software 
in accordance with operations carried out by the editor has 
been converted into description contents of an MHEG script 
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conforming to the MHEG-IS format. 

[0110] [0409] 'it should be noted that -the — pieces — e# 

proccooing — ohown — in^-Figs . 23 and 24 arc part — e#show the 
processing of the MHEG- script output control module 218 to 
convert the internal format of a description of an MHEG 
content into the MHEG-IS format. Ao described above, objecto 
o£ — fefee — piccco — ef — proccooing — ohown — ia — Figo . — 23 — aftd — 2-4 — a^e 
limited to oharcd objecto only. 

[0411] [0410] Thus, in actuality, processing to convert 

the internal format into the MHEG-IS format for an editing 
result of an MHEG content other than the shared scene is 
carried out concurrently with the piccco of processing shown 
in Figs. 23 and 24. 

[0412] [0411] In addition, the pieces of processing 

shown in Figs. 23 and 24 are each typical processing to the 
bitter end. There are other conceivable processing 

procedures for converting description contents with the 
internal format of the MHEG authoring software using the 
concept of shared scenes into description contents with the 
MHEG-IS format based on the concept of shared objects. 

[0413] [0412] The above embodiment is exemplified by a 

case in which — a — data — broadcaot — content — in the digital 
satellite broadcasting -i-e system created in accordance with 
the MHEG specifications. In addition, a content created by 
the present invention can also be used in media other than 
the digital satellite broadcasting system. As for the media, 
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a recording medium such as a CD-ROM can also be used in 
addition to distribution through a broadcasting system and a 
network . 

[0114] [0413] Furthermore, while the embodiment is 

exemplified by a case in which an MHEG content is edited, 
the present invention can also be applied to applications 
other than the MHEG system provided that the other 
applications conform to specifications for creating an 
interface picture (a content) introducing a concept similar 
to_j_ for example^ the concept of a shared object. 

[0415] [0414] As described above, the present invention 

defines a shared scene that can be created by using any 
arbitrary objects as a virtual scene usable as a scene 
common to scenes instead of directly handling the shared 
object on an authoring tool in editing work to create a 
content conforming to typically the MHEG specifications. In 
addition, the present invention is used for editing scenes 
in shared-scene units. Then, a rcoult of the editiftged work 
using the shared scene is finally converted into description 
contents for controlling a shared object itself in 
accordance with specifications for a content for 
broadcasting . 

[0416] [0415] With such a configuration, an editor 

creating a content is capable of handing a shared object by 
carrying out operations to combine shared scenes created 
arbitrarily for a scene at an editing-operation stage using 
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the authoring tool. Conversely speaking, it is not necessary 
for the editor to have do work requiring advance knowledge of 
MTTgn nn-riph minh nn doocription of an the MHEG script MHEG 
ocript — £e*? — opocif ying a — dioplay format — e£ — a — shared object 
from the beginning by uoing the authoring tool . 

[0417] [0416] Thus, by virtue of the present invention, 

the editor is capable of editing a scene using a shared 
object with ease and with a high degree of accuracy even if 
the editor is not familiar with rules of an MHEG script, for 
example. As a result, the present invention provides an 
effect to give the editor a capability of creating a scene 
in a number of display formats through editing operations 
which are easy to understand. 

[0418] [0417] In addition, as described above, the 

present invention provides a system of editing operations in 
which a shared object is handled for each shared scene and, 
in addition, an order of superposition of shared scenes can 
be specified. As a result, it is possible to simplify a 
comparatively complicated edit operation of specifying an 
order of superposition of objects. 

49906SJ 
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